Interactive guide — 04 · stepper
Anatomy of an MCP call
No — this is the most common confusion. The model only emits a structured request (a tool_call). A separate process executes it; the model never touches credentials, never makes the HTTP request, and only learns the outcome when the result is appended to its context.
Step through the transcript — watch the call leave the model's context, cross the wire, and come back.
File a Linear ticket: the login test broke after the session change.
The ask lands in context
Everything before this is plain conversation — the model sees your message plus a tool catalog: which tools exist, what arguments they take, and what they return. Tools are in-context knowledge, not code it runs.
capability — Tool callingAgents that speak MCP
Frequently asked
What is MCP, in one line?
A standard wire between an agent runtime and a tool server — JSON-RPC over stdio or HTTP — so any MCP-speaking agent can call any MCP server without bespoke integration code on either side.
Does the model execute the tool itself?
No — this is the most common confusion. The model only emits a structured request (a tool_call). A separate process executes it; the model never touches credentials, never makes the HTTP request, and only learns the outcome when the result is appended to its context.
Why does the boundary matter?
Because it puts secrets and policy outside the model's context. The Linear API key lives in the MCP server — it can't be leaked into a completion, and it can enforce its own validation, rate limits, and auth decisions independent of the model.
Is MCP the only way agents call tools?
No — plenty of agents use native function-calling or bespoke plugins. MCP's bet is standardization: one protocol for the wire, so tool servers and agent runtimes can be written independently and still interoperate.