A language model on its own is stuck behind glass. It can describe, in loving detail, how to restart your server. It cannot press the button. It's the world's most articulate backseat driver.
To be useful in the real world, it needs *hands* — ways to fetch real data and take real actions. Historically, giving it hands meant writing custom glue for every single tool, in every single app, forever. Every team reinvented the same plumbing. MCP is the industry collectively deciding to stop doing that.
What MCP actually is
The Model Context Protocol is a shared language between models and tools. An MCP server stands up and says: "here are the tools I offer, here's what each one needs, here's what it returns." Any MCP-aware client (a chat app, an IDE, an agent) reads that menu and can call what it needs. Write the integration once; every client gets it for free.
Before MCP, every tool integration was bespoke plumbing. After MCP, it's a plug.
Think USB, but for AI
Before USB, every device had its own cursed connector and you owned a drawer full of cables for hardware you no longer remembered buying. After USB: one port, many devices. MCP is trying to be that port between models and the messy reality of your tools and data.
An MCP server exposes three kinds of things:
- Tools — actions the model can invoke:
send_email,run_query,create_ticket. - Resources — data the model can read: files, database rows, documents.
- Prompts — reusable templates the server offers the client.
How a tool call actually flows
It's a clean little loop, and understanding it kills a lot of the mystique:
- 01The client asks the server for its list of tools and their descriptions.
- 02It passes those to the model along with the user's request.
- 03The model decides a tool is needed and emits a structured call with arguments.
- 04The client runs that call against the MCP server and feeds the result back to the model.
- 05The model uses the result to answer — or calls another tool.
A tool is smaller than you think
A tool definition is basically a name, a description the model *reads to decide when to use it*, and a typed input schema. That description is doing real work — write it like documentation for a colleague, not a variable name.
server.tool(
'get_order',
{
description: 'Look up a customer order by its id. Use when the user asks ' +
'about order status, contents, or shipping.',
input: { orderId: z.string().describe('The order id, e.g. ord_123') },
},
async ({ orderId }) => {
const order = await db.orders.find(orderId);
return order ?? { error: 'not found' };
}
);Tip
The model picks tools based on their descriptions. A vague description ("gets data") means the model uses it wrong or not at all. Treat tool descriptions as prompt engineering — because they are.
Designing tools the model can actually use
A few rules earn their keep once you've shipped a couple of these:
- One job per tool. A
manage_usertool that does six things confuses the model. Split it. - Return useful errors.
{ error: 'order not found' }lets the model recover; a thrown 500 just ends the conversation. - Keep results lean. Don't dump a 200-field object when the model needs five fields — you're paying tokens for the noise.
- Name things plainly.
cancel_subscriptionbeatssubMgmtV2Handler.
The part everyone skips: permissions
Giving an AI hands is great until it enthusiastically uses them. A tool that can delete_user will, eventually, get called on the wrong user at the wrong time. So scope tightly, require confirmation for destructive actions, log everything, and never expose a capability you wouldn't hand to a brand-new intern on day one.
Heads up
Read-only tools are your friend. Start there. Add write access deliberately, one capability at a time, with guardrails — not because the model is malicious, but because it's confidently fallible.
Why it matters
Once your systems speak MCP, the model stops being a clever text box and becomes an operator that can actually work *inside* your stack — with a clear, auditable list of what it's allowed to touch. That's the line between a neat demo and an assistant that earns its seat at the table.
Parrots are charming. But you hired the model to do the work, not narrate it.
Key takeaways
- 01MCP is a standard way to expose tools, data, and actions to AI models.
- 02Write an integration once; any MCP-aware client can use it — like USB for AI.
- 03Tool descriptions are prompt engineering, and permissions are not optional.
FAQ
Related reading