hawkes.aiKey ideas
- The one idea — An MCP server can expose three kinds of things — tools (actions the model calls), resources (data the model reads), and prompts (reusable templates the user invokes) — distinguished by who's in control.
- How it is shown — A server presenting three trays: tools (model-invoked actions), resources (app-provided readable data), prompts (user-invoked templates/slash-commands).
- The trap to avoid — Thinking MCP is only about tools/actions — it also standardizes read-only data (resources) and reusable prompts; use the right offering for the right job.
- What it sets up — Enough theory — build one.
Most people think MCP servers just serve tools. They can offer three different things — and the way to tell them apart is asking one question: who's in control?
The one idea
An MCP server can expose three kinds of things — tools (actions the model calls), resources (data the model reads), and prompts (reusable templates the user invokes) — distinguished by who's in control.
It's tempting to think an MCP server just offers tools — actions to call. But it can offer three distinct kinds of things: tools, resources, and prompts. And the cleanest way to tell them apart is to ask who's in control of each. That one question sorts all three. First, tools. These are actions the model can call to do things — send an email, query a database, run code. Model-controlled: the model decides, mid-loop, to invoke one. This is exactly the tool calling you've already seen, now offered through MCP in a standard way. Tools are for doing. Second, resources. These are data the server exposes for the model to read — a file's contents, a record, a document.
How it works — the demo
A server presenting three trays: tools (model-invoked actions), resources (app-provided readable data), prompts (user-invoked templates/slash-commands).
Not actions, but readable context. Application-controlled: the app decides what to load in, like handing the model the right attachment. Tools do; resources are simply read. Third, prompts. These are pre-written prompt templates the server offers — a ready-made summarize this pull request workflow, for instance. User-controlled: surfaced as commands the user picks, often as slash-commands. They're reusable, packaged instructions, so common workflows become a single click instead of retyping. So the real distinction is control. Tools are model-invoked — it chooses to act. Resources are app-provided context — read, not acted on. Prompts are user-invoked templates.
The trap to avoid
Thinking MCP is only about tools/actions — it also standardizes read-only data (resources) and reusable prompts; use the right offering for the right job.
Why it matters — and what’s next
Enough theory — build one.
Three offerings, three different hands on the wheel, three different jobs: do, read, and reuse. Ask who controls it, and each one's role is obvious. The trap: thinking MCP is only about tools and actions. It also standardizes providing read-only data, as resources, and reusable prompt templates. Cram everything into tools — turning data and templates into fake actions — and your design blurs. Use the right offering for the right job, and the whole system stays clean. So an MCP server offers tools to do, resources to read, and prompts to reuse — model-invoked, app-provided, user-invoked. That's the whole model, and it's cleaner than the jargon suggests. Enough theory, though. It's time to build one. Next group: wire your first MCP server — and then face its security surface.
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
It's tempting to think an MCP server just offers tools — actions to call. But it can offer three distinct kinds of things: tools, resources, and prompts. And the cleanest way to tell them apart is to ask who's in control of each. That one question sorts all three.
First, tools. These are actions the model can call to do things — send an email, query a database, run code. Model-controlled: the model decides, mid-loop, to invoke one. This is exactly the tool calling you've already seen, now offered through MCP in a standard way. Tools are for doing.
Second, resources. These are data the server exposes for the model to read — a file's contents, a record, a document. Not actions, but readable context. Application-controlled: the app decides what to load in, like handing the model the right attachment. Tools do; resources are simply read.
Third, prompts. These are pre-written prompt templates the server offers — a ready-made summarize this pull request workflow, for instance. User-controlled: surfaced as commands the user picks, often as slash-commands. They're reusable, packaged instructions, so common workflows become a single click instead of retyping.
So the real distinction is control. Tools are model-invoked — it chooses to act. Resources are app-provided context — read, not acted on. Prompts are user-invoked templates. Three offerings, three different hands on the wheel, three different jobs: do, read, and reuse. Ask who controls it, and each one's role is obvious.
The trap: thinking MCP is only about tools and actions. It also standardizes providing read-only data, as resources, and reusable prompt templates. Cram everything into tools — turning data and templates into fake actions — and your design blurs. Use the right offering for the right job, and the whole system stays clean.
So an MCP server offers tools to do, resources to read, and prompts to reuse — model-invoked, app-provided, user-invoked. That's the whole model, and it's cleaner than the jargon suggests. Enough theory, though. It's time to build one. Next group: wire your first MCP server — and then face its security surface.