Choose a scenario and click Next step. Each numbered step names its sender, receiver and operation. The preview explains the next action before you advance. A fictional Northbank colleague wants the Manchester office travel rule. The host manages conversation and permissions; its MCP client exchanges messages with the policy server. The lookup tool belongs to that server. A separate payroll client and server remain unused. Previous revisits a step, and Replay starts the same scenario again.
The blue Host Application and purple MCP Server show logical ownership, not physical deployment. Servers and models may run remotely. Requests cross towards the server; responses return to the client. Method names and IDs connect each response to its request. Local host decisions and internal tool work are labelled separately. The current message sits with the explanation of that step.
This trace follows MCP 2026-07-28, with per-request protocol metadata and server discovery. Earlier versions use a different connection lifecycle. Permission denial ends locally, an unknown tool returns a protocol error, and a failed tool returns isError. Every example is synthetic and performs no external action.
Sources and model assumptions
Follow the original mechanism behind this explainer. The interactive examples identify their toy data and simplifying assumptions above.
Put it to work
Related terms
- MCP (Model Context Protocol)MCP is an open standard for connecting agents to tools and data. Instead of hard-coding an integration into every agent, you run an MCP server once and any MCP-aware agent can use it.
- Tool callA tool call is the model’s request to use a tool: it names the tool and supplies the arguments, then pauses. It has not run anything. Your harness is what actually executes the action.
- Tool useTool use lets a model do more than produce text: you expose named actions with typed inputs, and the model calls them to read data, run code, or reach the outside world. It is the bridge from talking to doing.