hawkes.aiKey ideas
- The one idea — MCP has two roles — a client (inside the host app the model runs in) and a server (wrapping a tool/data source) — exchanging a defined set of messages: the client discovers what's available and calls it; the server responds with capabilities and results.
- How it is shown — The client asks a server "what can you do?" (discovery), the server lists its capabilities, the model calls one, the client sends the request, the server executes and returns the result into context.
- The trap to avoid — Thinking the model "speaks MCP" or connects directly — the host app's client handles the protocol; the model just emits tool calls, and the server does the work.
- What it sets up — A server offers more than actions — three distinct kinds of things.
The model never speaks MCP. It just emits tool calls, same as ever. A client in the app handles the protocol; a server wraps the tool. Two roles, few messages.
The one idea
MCP has two roles — a client (inside the host app the model runs in) and a server (wrapping a tool/data source) — exchanging a defined set of messages: the client discovers what's available and calls it; the server responds with capabilities and results.
MCP is a standard connection — but a connection has two ends. On one side, a client, inside the AI app the model runs in. On the other, a server, wrapping a tool or data source. Understand these two roles and the messages between them, and you understand MCP. The client lives in the host — your chat app, your coding agent, whatever the model runs inside. On startup, the host opens one such client per MCP server it uses. It's the model's side of the plug, handled by the app, not the model itself. The server is a small program wrapping a capability — your files, a database, an API, a service like GitHub — and exposing it through MCP.
How it works — the demo
The client asks a server "what can you do?" (discovery), the server lists its capabilities, the model calls one, the client sends the request, the server executes and returns the result into context.
Anyone can write one. It's the tool's side of the plug, speaking the standard so any client understands it. Now what flows between them. First, discovery: the client asks the server, what can you do? The server lists its capabilities. Then use: the model calls one, the client sends the request, the server executes and returns the result. That result flows back into the model's context, and it continues — the ask, execute, feed-back loop from tool calling, now over a standard channel instead of bespoke wiring. The client asks, the server answers, the model uses what comes back.
The trap to avoid
Thinking the model "speaks MCP" or connects directly — the host app's client handles the protocol; the model just emits tool calls, and the server does the work.
Why it matters — and what’s next
A server offers more than actions — three distinct kinds of things.
The trap: imagining the model speaks MCP, or dials servers directly. It doesn't. The host app's client handles the protocol on the model's behalf; the model just emits tool calls. And the server, not the model, does the actual work. So MCP is a client inside the app and a server wrapping a tool, exchanging messages: discover, then call. The model just uses the results. But a server offers more than actions — three distinct kinds of things. Next: MCP's three offerings.
This is one short episode in AI: Zero → Frontier, a step-by-step climb through how AI actually works. Each episode builds only on the ones before it.
Full transcript 2:30 of narration
MCP is a standard connection — but a connection has two ends. On one side, a client, inside the AI app the model runs in. On the other, a server, wrapping a tool or data source. Understand these two roles and the messages between them, and you understand MCP.
The client lives in the host — your chat app, your coding agent, whatever the model runs inside. On startup, the host opens one such client per MCP server it uses. It's the model's side of the plug, handled by the app, not the model itself.
The server is a small program wrapping a capability — your files, a database, an API, a service like GitHub — and exposing it through MCP. Anyone can write one. It's the tool's side of the plug, speaking the standard so any client understands it.
Now what flows between them. First, discovery: the client asks the server, what can you do? The server lists its capabilities. Then use: the model calls one, the client sends the request, the server executes and returns the result.
That result flows back into the model's context, and it continues — the ask, execute, feed-back loop from tool calling, now over a standard channel instead of bespoke wiring. The client asks, the server answers, the model uses what comes back.
The trap: imagining the model speaks MCP, or dials servers directly. It doesn't. The host app's client handles the protocol on the model's behalf; the model just emits tool calls. And the server, not the model, does the actual work.
So MCP is a client inside the app and a server wrapping a tool, exchanging messages: discover, then call. The model just uses the results. But a server offers more than actions — three distinct kinds of things. Next: MCP's three offerings.