The End-to-End Request Flow
Following One Question All the Way Through
Let's trace exactly what happens when a user asks an MCP-powered app a question that needs an external tool — for example, 'What repositories do I have?' against a GitHub MCP server. This is the single most important flow to internalize, because every component you'll build later plays a specific role in it.
The cast
Five players: the USER, your APPLICATION (host), the MCP CLIENT, the MCP SERVER, and CLAUDE (the language model). The MCP client's job is to abstract away server communication so your app can focus on logic.
The Eleven Steps
Yes, there are a lot of steps — but each component has one clear responsibility, and the pattern repeats for every tool-using request:
- 1.User query: the user submits 'What repositories do I have?' to your application.
- 2.Tool discovery: your app needs to know what tools exist to offer Claude.
- 3.List tools: your app asks the MCP client for available tools.
- 4.MCP communication: the client sends tools/list to the server and gets back the tool definitions.
- 5.Claude request: your app sends the user's question plus the available tools to Claude.
- 6.Tool-use decision: Claude decides it needs a tool and replies with a tool_use request (e.g. get_repos).
- 7.Tool execution request: your app asks the MCP client to run the tool Claude chose.
- 8.External API call: the client sends tools/call to the server, which calls GitHub's real API.
- 9.Results flow back: GitHub responds; the data returns through the server as a tools/call result.
- 10.Tool result to Claude: your app sends the tool's result back to Claude.
- 11.Final response: Claude composes a natural-language answer, which your app delivers to the user.
The MCP client mediates between your app and the server; your app mediates between the client and Claude. Each arrow is one responsibility.
Who Does What
| Component | Responsibility in the flow |
|---|---|
| Your app (host) | Orchestrates: gets tools from the client, sends them + the query to Claude, runs tools Claude asks for, returns the final answer |
| MCP client | Speaks the protocol: turns 'list tools' / 'run tool' into tools/list and tools/call messages and back |
| MCP server | Implements the integration: exposes tool definitions and executes them against the real service (GitHub) |
| Claude (LLM) | Decides: chooses whether/which tool to call, then writes the final answer from the tool's result |
The clean division of labor that makes the many-step flow manageable.
Claude never touches the server directly
A subtle but crucial point: Claude doesn't call MCP servers. Claude only emits a tool_use request; YOUR APP (via the MCP client) executes it and feeds the result back. This keeps the model decoupled from infrastructure and keeps you in control of what actually runs.
Why So Many Steps Is Actually Good
The multi-step flow can look heavy, but the indirection is the feature. Because the MCP client abstracts server communication, your application logic stays simple — you ask for tools and run tools without caring how the server is implemented or where it lives. Because Claude only proposes tool calls, you can add approval gates, logging, or policy checks at the execution step. Each seam is a place to add control, safety, and observability.
Section complete
You can now narrate a full MCP request end-to-end. Next section gets hands-on: we build a real MCP server with the Python SDK, starting with tools.
Key Takeaways
- ✓The core flow has 11 steps across 5 players: User, your App (host), MCP Client, MCP Server, and Claude.
- ✓Discovery first: the app gets tool definitions via the client (tools/list) before sending them with the query to Claude.
- ✓Claude only DECIDES — it emits a tool_use request; it never calls the MCP server itself.
- ✓Execution: the app asks the client to run the chosen tool (tools/call); the server calls the real API and returns the result.
- ✓The app then feeds the tool result back to Claude, which writes the final natural-language answer.
- ✓The indirection is a feature: each seam (client abstraction, app-controlled execution) is where you add simplicity, safety, approvals, and logging.
Check Your Understanding
Test what you learned in this lesson.
Q1.In the end-to-end flow, what does Claude actually do when a tool is needed?
Q2.Before sending the user's question to Claude, what must the application do first?
Q3.What does the MCP client contribute in this flow?
Q4.Why is the multi-step indirection considered a benefit rather than overhead?
Practice This Lesson