feat(mcp): let ap_update_step change a piece step's version - #155
feat(mcp): let ap_update_step change a piece step's version#155AdamSelene wants to merge 2 commits into
Conversation
Adds an optional `pieceVersion` param to the ap_update_step MCP tool. Pass "latest" to upgrade to the newest version, or an exact version to pin it. The LLM then adjusts `input` in the same call to handle schema changes between versions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Hey — thanks so much for taking the time to open this! 🙏 We've temporarily paused unsolicited pull requests from outside the core team. This isn't about you or the quality of your change — an open PR is a promise from us to review it carefully, and right now the volume (a lot of it AI-generated) means we can't keep that promise for every PR without it becoming unfair to contributors who wait weeks for a reply. So instead of leaving PRs hanging, we close them and point you to a faster path. Already working with us? If you're an existing customer and we've already discussed this change over Slack, ping us there and we'll add the You can still build and publish your own piece — just outside this repo, as your own package rather than a PR here. See CONTRIBUTING.md for the full policy. Thanks again for caring about the project. 💜 |
Hopper reviewReview failed.
|
The explicit-version branch validated the requested version but stored it as a `~` patch range. The flow apply layer strips the prefix so the persisted version was still exact, but the intermediate range was fed to the unknown-input-prop validation, which resolved it to the highest matching patch and validated input against a different schema than the one that runs. Store the exact requested version so validation targets the version the step will actually execute. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Description
Adds an optional
pieceVersionparameter to theap_update_stepMCP tool so an AI client can move a PIECE step onto a different version of its piece:"latest"— resolves to the newest available version (reusesresolveLatestPieceVersion, the same helperap_update_triggeralready uses to keep triggers on the latest version)."1.2.3"— validated against the piece registry (friendly error if it doesn't exist) and pinned as~1.2.3, matching how step versions are stored everywhere else.After the version is set, the existing flow-update path re-validates the step against the new action schema and diagnoses missing/unknown inputs, so the LLM can pass an adjusted
inputin the same call to handle properties that were removed, renamed, or added between versions.Previously
ap_update_stepalways copied the existingpieceVersionand had no way to upgrade an action step — triggers already auto-bumped, actions did not.How was this tested?
npx turbo run lint --filter=api— 0 errors. Change is confined toap_update_step; no new tool registration,disabledToolsschema, or web settings wiring needed.Breaking change? (required — CI fails if this is left unedited)
Security impact? (required — CI fails if this is left unedited)
🤖 Generated with Claude Code