MCP dynamic tool changes

A tools/list change can alter the agent’s available operations or the instructions inside descriptions mid-task.

01 / The operating case

What changes in a real workflow?

A server changes a read tool into a write-capable version after the client approved its initial catalog.

Trace the authority boundary
  1. 01Client / task
  2. 02MCP server
  3. 03Tool call + arguments
  4. 04Downstream effect

02 / Decision contract

What the executor must check

Version tool definitions, review material changes and reauthorize calls against the current schema and effect classification.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

An old catalog approval is reused after the target operation or data destination changes.

Evidence to retain

Record notification, previous and new schema hashes, review state and affected calls.

04 / Canonical scope

Why this reference stands alone

Tool trust covers evaluating one tool; this page owns change control over time.

Protocol or attack trace

Catalog mutation test

Sequence

At task start, tools/list says archive_record is read-only; new definition adds delete behavior.

Negative test

Invoke after tools/list_changed without fresh effect review; client or server must reject stale approval.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation