MCP, explained by what it actually replaces

The Model Context Protocol is described as a standard for connecting AI to tools, which tells you nothing. Here is the concrete problem it removes, from someone running half a dozen of these servers daily.

Most explanations of the Model Context Protocol start with the phrase 'a standard way to connect AI models to external tools and data', which is accurate and completely useless. It tells you the category, not the problem. The clearer way in is to look at what building this looked like before, because the protocol is a direct response to a specific mess.

The problem it removes

Say you want an assistant that can read your issue tracker, search your team's wiki, and drive a browser. Without a shared protocol, you write three integrations, and each one is a full set of decisions: how to describe the available operations to the model, how to shape the arguments, how to authenticate, how to return results, how to report failures, how to handle the model asking for something that does not exist.

None of that work transfers. Change the assistant and you write all three again. Add a fourth service and you write a fourth adapter. Worse, everyone else integrating that same issue tracker is writing their own version of the same thing, and none of them can share it.

MCP makes the integration a separate process that speaks a defined protocol. The service exposes what it can do; the client discovers those capabilities and presents them to the model. The adapter is written once by whoever knows that service best, and any compliant client can use it.

It is less an AI innovation than an ordinary interface boundary, applied somewhere that had none.

The three things a server exposes

The vocabulary is small, which is most of why it works.

• Tools: actions the model can invoke. Create an issue, run a query, click a button. These have side effects and are the ones worth being careful about.
• Resources: data the model can read. A document, a file, a record. Read-only context rather than an operation.
• Prompts: reusable templates the server offers for common tasks against it, so the useful phrasing lives with the service instead of in every user's head.

Most servers in practice are mostly tools. The distinction that earns its keep is tools versus resources, because it maps directly onto the question of what can change state.

What running several of them is actually like

I have servers connected for an issue tracker, a chat platform, a design tool, browser automation and browser devtools. Genuine observations from using that setup rather than reading about it:

The value is concentrated in a few. Two or three get used constantly and the rest sit idle for weeks. The useful ones share a property: they reach something with real state that I would otherwise have to go and look at by hand. A server wrapping something I could describe in a sentence adds nothing.

Tool descriptions matter more than the implementation. The model chooses what to call based on the description text, so a vague one produces wrong calls no matter how correct the underlying code is. Writing an MCP server is largely a documentation exercise wearing an engineering costume.

Loading everything at once is a real cost. Each server contributes its full schema to the model's context, and a dozen servers with a dozen operations each is a substantial slice of the window spent describing capabilities before any work begins. Fetching schemas on demand rather than upfront is a meaningful improvement, and the fact that clients now do this is a hint about how quickly the naive approach stopped scaling.

The part that deserves genuine caution

A tool call is a real action against a real system. If the model is deciding what to call based partly on content it just read, and that content contains text aimed at influencing it, you have a straightforward injection path from data into actions.

This is not hypothetical and it is not exotic. A page, a ticket description, a file comment: anything the model reads can carry instructions. The mitigation is boring and structural rather than clever: treat everything read through a resource as data and never as instruction, require confirmation for anything with side effects that reach outside the machine, and be sceptical of a server that wants broad write access to something you care about.

The protocol standardises how the model reaches your systems. It does not standardise the judgement about whether it should.

When to write one

Write a server when you have a system with meaningful state that you keep manually shuttling into a conversation, and when the operations you want are stable enough to describe once. Copying the same query results into a chat window three times a week is the signal.

Do not write one to wrap a single HTTP endpoint, and do not write one for a task you do once a month. The setup cost is small but not zero, and an unused server still occupies context in every session it is connected to.

The honest summary is that MCP is unglamorous infrastructure that does something genuinely useful: it turns integration work into something reusable. That is a much smaller claim than most of the writing about it makes, and it is the reason the protocol is worth understanding rather than the reason it gets discussed.