MCP, and why a standard for tools matters

The N times M problem

You have six agents. Your company runs nine systems — Jira, Postgres, Google Drive, Slack, a CRM, a warehouse API, and so on. Without a standard, that is potentially fifty-four integrations, each written against a particular framework's tool format. Rewrite the agent in a different framework and you rewrite all nine connectors.

This is the same problem editors had with language tooling. Every editor needed a plugin for every language: N times M. The Language Server Protocol collapsed it into N plus M — write one server per language, one client per editor — and it stuck, because the underlying pain was real.

MCP (Model Context Protocol) is the same move for tools. Anthropic released it in late 2024 and it has since been adopted well beyond Anthropic. It defines a JSON-RPC conversation between a client (your agent or app) and a server (something exposing capabilities). The server advertises its tools with names, descriptions and schemas. The client asks for that list, hands it to the model as ordinary tool definitions, and when the model requests one, the client calls the server.

What you get for that: the integration is written once and works in any MCP client. A Postgres server someone published works in your custom loop, in an IDE, in a desktop app. That is the entire value proposition, and it is genuinely large.

What it explicitly does not do

This is where people get disappointed, so let us be direct.

It does not make the model use tools well. A badly-described MCP tool is a badly-described tool. Everything from lesson two still applies, and now the description was written by a stranger who did not have your use case in mind.

It does not solve your context problem — it usually worsens it. Connect four servers and you may inject seventy tool definitions into every single request. Teams regularly find their agent got *worse* after adding servers, and are puzzled, because adding capability is supposed to help. It is the same problem as before: past roughly twenty tools, selection accuracy falls, and the failure is quiet.

Auth is the messy part. Getting credentials safely from a user, through a client, into a server that acts on their behalf has been the least settled area of the spec and the most common source of real security mistakes.

The model does not know MCP exists. This is worth saying plainly, because it is a common confusion. The model sees ordinary tool schemas that the client rendered for it. MCP is plumbing between your code and a server. It never reaches the model.

Being honest about churn

The ecosystem is young and it moves. The transport has already changed once (server-sent events gave way to streamable HTTP). Servers you install today may need updating. Some published servers are excellent; many are a weekend project with no error handling, which matters enormously given that error strings are your agent's only feedback.

None of that means avoid it. It means: pin versions, read the server's source before granting it credentials, and expect maintenance. The direction — a shared interface between models and tools — is not going away, because N times M is not going away.

Practical rules

1. 1Connect the fewest servers that do the job. Not the most impressive set.
2. 2Filter the tool list. Most clients let you enable a subset. Expose eight tools from a server that offers thirty.
3. 3Read descriptions before trusting them. If a server's tool descriptions are one-liners, your agent will misuse them, and you can often override.
4. 4Treat a third-party server as untrusted code with network access. Because that is what it is.