On Monday an agent proposes create_booking(room_id, date) and pauses for human approval. On Tuesday the tool server deploys a new schema that requires rate_plan_id. The approved call is still in durable state, but the tool name now resolves to a different contract. Replaying the saved JSON blindly can fail validation. Filling the new field with a guessed default may be worse because the human never approved that booking.

Tool discovery is time-dependent. The MCP tools specification describes tool input schemas and notifications when the available tool list changes. Such a notification can refresh what the agent sees next, but it does not retroactively change the meaning of an already approved action.

Store the proposed tool identity, schema or contract version, exact arguments, human approval scope, and any resource versions needed to execute safely. At resume, either route to a compatible version of the tool or run an explicit migration that preserves the approved meaning. If migration requires a material new choice, stop and ask for a fresh approval of the concrete revised operation. Validation is a useful guardrail, but “it now passes the new schema” is not proof that the old intent was preserved.

Make deployment compatible with outstanding work. For example, keep create_booking_v1 callable until old approvals drain, or build a migration that can derive rate_plan_id from an immutable reservation quote already shown to the user. If the quote expired, reprice and seek a new decision. A tool schema can be additive at the JSON level and still change business semantics through a new default, so review both syntax and effect.

Test a paused run across a rolling tool deployment. Confirm that the model cannot rewrite the approved arguments during resume, that the executor rechecks current authorization, and that an audit links the eventual call to the version the human approved. An agent's long lifetime makes tool API evolution part of workflow correctness, not just SDK compatibility.