A standalone companion to lesson 3.1. No laboratory or prior lesson is needed. Consider a tool that proposes publishing a specific note to a specific board and requires a decision before publication.
sequenceDiagram
participant C as Client
participant S as Server
participant U as User
C->>S: Propose note (request A)
S-->>C: input_required + form + opaque state
C->>U: Show target and exact text
alt Submitted decision
U-->>C: Accept, decline, or cancel
C->>S: Same operation + answer + exact state (request B)
S->>S: Validate identity, subject, lifetime, and lifecycle
S-->>C: Application outcome
else No retry
Note over C,S: No new decision reaches the server
end
The diagram's proposal storage and publication policy are illustrative application choices. The wire pattern carries the input exchange; it does not establish that a human actually interacted with the client.
| Observation | What it establishes | Next useful check |
|---|---|---|
resultType: input_required | The operation needs another input step | Inspect inputRequests and client support |
| Form displayed | The client presented a question | Determine whether an answer was submitted |
| Retry sent | Another exchange was attempted | Match input keys and original operation context |
| Different RPC ID | A separate exchange is being correlated | Preserve the business operation identity |
| Intact continuation | Integrity verification may succeed | Still check caller, subject, expiry and consumption |
| No follow-up request | No new input was received | Keep unapproved work from committing; enforce lifetime |
| Missing answer after acceptance | Client outcome remains uncertain | Query the application's authoritative status/receipt |
Practice cases
- The server returns a form but the client never displays it. Inspect the advertised form capability and the branch that handles input-required results. Increasing a timeout does not supply a missing decision.
- The retry carries the approval but changes the target board. Reject a continuation that no longer matches the approved subject; inspect the effect as well as the response so a late error cannot hide a premature write.
- Acceptance was sent and the connection ended without a final response. Find the application's outcome evidence before creating a new operation. A missing response is compatible with a committed effect.
Do not interpret client display names or user-entered identity as verified caller identity. Do not infer human participation from an acceptance payload.
Primary sources checked 2026-09-09: MRTR, elicitation.
Lesson 3.1 · The missing approval that blocks a tool call
The sheet is the diagnosis. The course is the fix.
Lessons 3.2 to 3.4 build the input-required result and the client retry with Multi Round-Trip Requests, then test refusal, abandonment and a restart mid-approval in lab 3. Every lab runs on your machine with Docker Compose, and each one ships tests that break the code on purpose so you see them catch it.
Free · four printable pages
The 2026-07-28 migration cheatsheet
Every breaking change next to what replaces it, the error codes and the deprecation clock. We'll email it to you.
More free sheets#
- Your MCP server fails on one replica. Start with the request. Lesson 1.1
- One MCP request, field by field. Lesson 1.2
- Was it the transport, the protocol or the tool? Lesson 1.3
- Your MCP tool timed out. Did the write happen? Lesson 2.1
- Health check green, MCP tool still failing. Lesson 8.1
- What MCP 2026-07-28 breaks, and what's only deprecated. Lesson 9.1