Approval must bind to an exact intent

The mechanism

Human approval is useful only if the executor can identify what was approved. A vague “yes” should not authorize an arbitrary later tool call. Bind an approval to the authenticated reviewer, target object, operation, exact payload, expected revision and expiry.

ParcelOps may eventually propose adding a note. The proposal is reviewable data first. After approval, the executor compares the current request and object revision with the approved intent. If either changes, the approval no longer applies. This is an application design layered above MCP, not a built-in guarantee of the protocol.

Retries need a separate business idempotency key. A network response can disappear after the note was created. The service must reconcile or deduplicate the same intended action atomically, including concurrent requests and process crashes.

Worked example

This approval design fixture intentionally has no usable credential. The hash represents canonicalized business intent, not a Python object’s unstable string representation. The executor must obtain approval from trusted application state, never from a model-supplied “approved” flag.

{"operation":"append_note","target":"INC-104","expected_revision":7,
 "payload":{"text":"Carrier scan still missing; investigate next checkpoint."},
 "approval":{"state":"not_requested","reviewer":null,"expires_at":null},
 "idempotency_key":"synthetic-intent-001","execution":"not_run"}

Practice: predict, inspect, explain

Offline exercise. Approve the fixture on paper, then change the note text, target, revision and expiry one at a time. Each change should invalidate execution unless covered by a new review. Simulate a timeout after a successful append and describe how a retry locates the existing effect.

Expected observation: approval, authorization and idempotency are separate checks. A valid approval does not override revoked permissions, and a stable request ID does not create durable deduplication. Use the offline capstone to test intent binding without writing any incident data.

Troubleshooting and trade-offs

If approvals survive arbitrary payload edits, inspect what is actually compared at execution. If two workers create duplicate notes, move deduplication to an atomic destination-side boundary. A local dictionary can illustrate the idea but does not prove distributed exactly-once behavior. Log intent identifiers and outcomes while keeping sensitive note contents out of routine telemetry.

Interview practice

Completion check

Reject changed-payload and stale-revision cases, then explain recovery after an unknown write outcome.

Sources and version notes

This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.

• Official documentation: Tools
• Official documentation: Security best practices
• Official documentation: Cancellation