// the gap
Ask a model about your production database and it will happily explain your schema, reason about your indexes, and propose a migration. Ask it for one actual row and it cannot help you. It has no hands.
That is not a knowledge problem, it is a wiring problem. The model is a text function: text in, text out. Everything else — reading a file, calling an API, editing code — has to be handed to it as a tool that your application actually executes.
What MCP is
The Model Context Protocol is one standard way to hand a model real capabilities: read this database, call that API, edit these files. You write the tool once as an MCP server, and any MCP-speaking app can use it.
Before it, every AI app needed its own bespoke integration with every tool — the M×N problem. MCP turns that into M+N: N tools each wrapped once, M apps each speaking one protocol.
What it actually unlocks
The shift is from describing the work to doing it. A model with tools stops writing you a SQL query to run yourself and starts returning the answer.
resources (data the app pulls in as context) and prompts (reusable templates the user invokes). Reaching for a tool when a resource fits is the most common early mistake — the primitives page covers the split.The rule
If your assistant can only ever tell you about your systems, it has no tools — and no amount of better prompting will change that. Giving it one real capability, wrapped once, changes what it is.
Next: how MCP works under the hood — the M×N problem, the three primitives, and the transports.
One concept a week. Free.
The deeper, copy-paste version of each ToolCall short — in your inbox.
// total: 0.00 · spam: void · unsubscribe: one click