Skip to content
MCPA Exam Prep

Tool Invocation Lifecycle

Lifecycle stages

Section titled “Lifecycle stages”
  1. Declaration — the server advertises the tools capability (via server/discover in the 2026-07-28 revision; via the initialize handshake in earlier revisions)
  2. Discovery — the client calls tools/list (paginated) and receives tool definitions
  3. Exposure — the host translates definitions into the LLM’s tool format
  4. Selection — the model chooses a tool based on name, description, and schema
  5. Authorization — the host applies policy / requests user consent (human-in-the-loop)
  6. Invocation — the client sends tools/call with name and arguments
  7. Execution — the server validates inputs and performs the action
  8. Result — the server returns content (+ optional structuredContent), with the isError flag
  9. Integration — the host inserts the result into model context; the model continues
flowchart TD
A[1 Declaration<br/>tools capability] --> B[2 Discovery<br/>tools/list]
B --> C[3 Exposure<br/>LLM tool format]
C --> D[4 Selection<br/>model picks tool]
D --> E[5 Authorization<br/>consent / policy]
E --> F[6 Invocation<br/>tools/call]
F --> G[7 Execution<br/>server runs action]
G --> H[8 Result<br/>content + isError]
H --> I[9 Integration<br/>into model context]
Tool invocation lifecycle

tools/call example

Section titled “tools/call example”
{
  "jsonrpc": "2.0",
  "id": 5,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "Madrid" }
  }
}

Result content types

Section titled “Result content types”
Type Description
text Plain text output (most common)
image / audio Base64 data + MIME type
resource_link URI pointing to a resource the client can fetch
Embedded resource Full resource content inline
structuredContent JSON value conforming to the tool’s outputSchema (if one is defined); for backwards compatibility it should also be mirrored in a text block

Long-running calls

Section titled “Long-running calls”
  • Progress: the request can include a progressToken in _meta; the server emits notifications/progress updates (progress must increase with each notification)
  • Cancellation: the client cancels an in-flight call — on stdio by sending notifications/cancelled with the request id; on Streamable HTTP by closing the SSE response stream. The server should stop work and send no response
  • Timeouts: clients should enforce per-request timeouts and cancel on expiry

Tool annotations

Section titled “Tool annotations”

Tools can carry behavior hints:

Annotation Meaning Default
readOnlyHint Does not modify its environment false
destructiveHint May perform destructive updates true
idempotentHint Repeated calls with same args add no effect false
openWorldHint May interact with external entities true

Key exam points

Section titled “Key exam points”
  • Discovery is dynamic — tool lists can change; clients learn of changes via notifications/tools/list_changed (delivered over a subscriptions/listen stream in 2026-07-28)
  • Consent/authorization happens before the call reaches the server
  • A failed tool execution is a normal result with isError: true, not a JSON-RPC error
  • Annotations are hints, not security guarantees

Check your knowledge

Section titled “Check your knowledge”

📝 Check your knowledge

1. In the tool invocation lifecycle, when does user consent/authorization happen?
2. Which method does a client use to invoke a tool?
3. How does a client cancel an in-flight tool call over Streamable HTTP (2026-07-28)?
4. What does structuredContent in a tool result contain?
5. Why can't a host rely on readOnlyHint for a security decision?
6. A tool execution fails because an external API is down. What should the server return?