Skip to content

feat(mcp): let ap_update_step change a piece step's version - #155

Open
AdamSelene wants to merge 2 commits into
mainfrom
feat/mcp-update-step-piece-version
Open

feat(mcp): let ap_update_step change a piece step's version#155
AdamSelene wants to merge 2 commits into
mainfrom
feat/mcp-update-step-piece-version

Conversation

@AdamSelene

Copy link
Copy Markdown

Description

Adds an optional pieceVersion parameter to the ap_update_step MCP tool so an AI client can move a PIECE step onto a different version of its piece:

  • "latest" — resolves to the newest available version (reuses resolveLatestPieceVersion, the same helper ap_update_trigger already uses to keep triggers on the latest version).
  • an exact version like "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.
  • non-PIECE step — rejected with a clear message.

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 input in the same call to handle properties that were removed, renamed, or added between versions.

Previously ap_update_step always copied the existing pieceVersion and 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 to ap_update_step; no new tool registration, disabledTools schema, or web settings wiring needed.

Breaking change? (required — CI fails if this is left unedited)

  • no — reviewed, not breaking

Security impact? (required — CI fails if this is left unedited)

  • no — reviewed, no security impact

🤖 Generated with Claude Code

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>
@github-actions

Copy link
Copy Markdown

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 keep-open label and reopen this PR for review.

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-prod

hopper-prod Bot commented Aug 15, 2026

Copy link
Copy Markdown

Hopper review

Review failed.

Checkpoint restore failed

Open Hopper session

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant