MCP Is a Protocol, Not a Plugin System

An AI on its own can only write words. To let it actually do things — look up an order, send an email, search a database — you give it tools. A tool is a small described action the AI can choose to use.

The Model Context Protocol, or MCP, is an agreed standard for describing those tools, so any AI can use any tool without custom glue. It is genuinely useful and it is spreading fast.

And the first thing nearly everyone does with it is wrap an existing web service. You have fifteen endpoints, you expose fifteen tools, you point an AI at it, and the demo works. It feels like a plugin system, and plugin systems are a familiar shape — register a capability, the host calls it, done.

That feeling is exactly what makes the second week hard.

Your tool is read, not called

A plugin gets invoked by a program that knows precisely what it wants. A tool gets chosen by an AI that is guessing what it wants from a short description you wrote — and then reading whatever comes back and deciding what to do next.

Those are not the same contract. And the difference shows up as an agent that goes round in circles.

This changes what "good design" means. Consider a tool called search(query, filters, options). That is a perfectly respectable function signature and a bad tool. What counts as a filter? What happens if you leave it out? Is the page number inside options?

A human integrating with it reads your documentation once and remembers. An AI works it out afresh from your description on every single call — and where the description is thin, it guesses.

The fix is usually to split things up. Not one search with a mode switch, but search_customers_by_name and search_orders_by_date. Fewer inputs each, more tools overall, every one obvious on its own. And each description should say what it is for, what it gives back, and — the part almost everyone leaves out — when not to use it.

Error messages are instructions now

Normally, an error message is something a human reads in a log later.

Inside an AI agent, the error goes straight back into the AI's reading and becomes the entire basis for its next decision. It is not a diagnostic. It is an instruction, and you are the one writing it.

400 Bad Request tells the AI nothing. So it tries the identical call again, gets the identical error, and you have built a loop that will happily run until something stops it.

Error: invalid date format is better, but still incomplete — it says what went wrong, not what to do.

What actually breaks the loop is an error containing the correction:

invalid date format "next tuesday" — this field wants a date like 2026-09-17

Now the failure fixes itself on the next attempt. The difference between those two messages is the difference between a tool that recovers and a tool that burns through the AI's entire working memory.

The same logic applies to empty results. Returning nothing is ambiguous — did the search break, or is the answer genuinely "none"? An AI facing that ambiguity tends to assume it made a mistake and retry with variations. Whereas:

No orders found for customer 4021 in the last 30 days. This customer does exist.

ends the sequence, because it separates "no data" from "wrong question."

Every reply is a bill

An AI can only hold so much text in mind at once. That space is finite and shared by everything: the conversation, the instructions, and every reply your tools have sent back.

A web endpoint returning forty fields is being thorough. A tool returning forty fields has just spent a chunk of the AI's limited attention, and it will do it again on the next call, and the one after.

This flips a habit. The right default for a tool is the smallest reply that answers the question, not the most complete description of the thing. Return the five fields that matter. Offer a separate tool for the full record, so the expensive version is something the AI asks for when it needs it.

And the problem compounds. An agent making six tool calls before answering has paid for all six replies. If each is bloated, the AI is now trying to reason while most of what it can see is stale data from four steps ago.

Trimming what a tool returns is not a hack. It is the responsible default for something shared across the whole task.

Never rely on what happened before

The strongest argument that MCP is a protocol rather than a plugin API is that it forces a discipline plugin systems usually skip: every call has to make sense on its own.

You do not control the order. The AI might call your tool, wander off to three others, come back, or get interrupted and resumed in a completely different process an hour later.

A tool that quietly depends on having been called before — an invisible session, a remembered position in a list, a "current folder" — works beautifully in the happy path and produces baffling behaviour the moment the order changes. And the order always changes, because an AI chose it.

So put the state in the arguments. If your tool needs a session, the session ID is an input, handed back by whatever created it. This looks more verbose. It is the reason the tool still works when the agent does something you never imagined.

If you are wiring up your first server

• Expose fewer tools than you have endpoints. One per task, not one per route.
• Write descriptions for someone who cannot ask questions — and say when not to use it.
• Put the fix inside every error message, not just the complaint.
• Return the smallest useful reply; make the full version a separate tool.
• Never depend on call order. Put the state in the arguments.
• Read your own agent's transcripts. The loops are obvious once you look, and invisible until you do.

MCP standardises how tools are described and delivered. That is genuinely valuable, and it is the easy half. The design work it does not do for you is what decides whether your agent finishes the job or spends thirty turns rediscovering your date format.

That work is not plugin registration. It is writing for a reader.