Skip to content
MCPA Exam Prep

Model Interaction Flow

End-to-end flow

Section titled “End-to-end flow”

A typical tool-using interaction:

  1. Discovery — the client learns what the server offers. In the current spec (2026-07-28) the client calls server/discover to get supported versions and capabilities, then tools/list, resources/list, prompts/list. There is no initialize handshake anymore: protocol version, client info, and client capabilities travel as _meta fields on every request. (In legacy revisions, 2025-11-25 and earlier, a connection started with initialize → notifications/initialized.)
  2. Context assembly — the host converts MCP tool definitions into the model’s native tool-calling format and includes them in the model request
  3. User prompt — the user asks something; the host sends the conversation plus available tools to the LLM
  4. Model decision — the model decides a tool is needed and emits a tool-use request
  5. Consent — the host checks policy / asks the user for approval
  6. Invocation — the client sends tools/call to the server with the arguments
  7. Execution — the server executes and returns a result (or an in-band error with isError: true)
  8. Response synthesis — the host feeds the tool result back to the model, which produces the final answer for the user

Sequence diagram

Section titled “Sequence diagram”
sequenceDiagram
participant U as User
participant H as Host
participant L as LLM
participant C as Client
participant S as Server

C->>S: server/discover
S-->>C: versions + capabilities
C->>S: tools/list
S-->>C: tool definitions
U->>H: "What's the weather in Madrid?"
H->>L: prompt + tool definitions
L-->>H: tool_use: get_weather(location="Madrid")
H->>U: approve? (consent)
U-->>H: approved
C->>S: tools/call get_weather
S-->>C: result: temp 31, sunny
H->>L: tool result
L-->>H: "It's 31°C and sunny in Madrid."
H-->>U: final answer
Tool-using interaction

Important nuances

Section titled “Important nuances”
  • The model never talks to servers directly — the host/client mediates every call
  • Discovery results can change at runtime; servers emit notifications/tools/list_changed (and similar for resources/prompts). In the current spec the client must open a subscriptions/listen stream to receive them, then re-fetch the list
  • The host may loop the decision → consent → call → result steps multiple times (multi-step agentic workflows)
  • Sampling reverses the direction: the server asks the client to run an LLM generation (sampling/createMessage). Note that sampling is deprecated in 2026-07-28, and server-initiated needs now arrive inside a reply as InputRequiredResult (the MRTR pattern) rather than as server-initiated requests

Key exam points

Section titled “Key exam points”
  • Order matters: discover → model selects tool → consent → call → result → final response
  • The host translates between MCP tool definitions and the specific LLM’s tool-call format
  • The LLM only sees tool names/descriptions/schemas — never the server implementation

Check your knowledge

Section titled “Check your knowledge”

📝 Check your knowledge

1. In a typical tool-using flow, when does user consent happen?
2. Who converts MCP tool definitions into the model's native tool-calling format?
3. How does a client discover a server's capabilities in the 2026-07-28 revision?
4. What must a client do in the current spec to receive notifications/tools/list_changed?
5. Can the LLM call an MCP server directly?
6. How do server-initiated needs like sampling reach the client in 2026-07-28?