MCP Explained: One Protocol Instead of N×M Integrations

Before a standard existed, every AI application implemented its own integrations. Connecting five tools to four applications meant twenty separate pieces of work. That N×M problem is what the Model Context Protocol addresses.

The shape of it

MCP defines a client-server protocol. A server exposes capabilities — tools to call, resources to read, prompt templates. A client, embedded in an AI application, connects and makes those capabilities available to the model.

Write one server for your internal API and any MCP-capable application can use it. Write one client and every existing server becomes available. N+M rather than N×M.

Three kinds of capability

• Tools — actions the model can invoke. Query a database, create a ticket, run a search. These map onto ordinary tool calling.
• Resources — data the application can read and place in context. Files, records, documentation. Read-only, and typically selected by the application rather than the model.
• Prompts — reusable templates the server offers, usually surfaced to the user as commands.

The tools/resources split is the interesting part. Tools are model-driven; resources are application-driven. Blurring them is the most common design mistake — exposing a "read file" tool when the file should simply have been provided as a resource wastes a turn and a decision.

Transports

Servers run either as a local subprocess communicating over stdio, or as a remote HTTP service. Local is straightforward and inherits your machine's permissions. Remote needs authentication and introduces the usual concerns of exposing an API.

What it does not do

MCP standardises connection, not judgement. It does not make the model better at choosing tools, and it does not solve prompt injection — a malicious or compromised server can return content designed to manipulate the agent. Everything in the security discussion around tool calling applies unchanged.

It also does not remove the need for good tool design. A badly described MCP tool is exactly as unusable as a badly described local one.

When to write a server

Worth it when:

• Several different AI applications need the same capability.
• You want to share an integration beyond your own codebase.
• The capability is genuinely reusable — a data source, an internal service.

Not worth it when the tool is specific to one application and one workflow. A local function is simpler, faster, and has no process boundary. Introducing a protocol between two pieces of your own code buys nothing.

Practical cautions

1. Audit third-party servers. Installing one grants it whatever access it requests. Read the source, or do not run it.
2. Watch tool count. Several servers connected at once can push you past the point where model tool selection degrades. Enable what the task needs.
3. Scope credentials. A server holding a broad API token is a broad blast radius.
4. Expect churn. The ecosystem is young; pin versions rather than tracking latest.

Designing a server worth using

The same principles that make local tools work apply, with one addition: your server will be used by applications you did not write, driven by models you did not choose.

That means descriptions carry more weight than usual — they are the entire interface. State what a tool returns, when to reach for it, and what it explicitly does not cover. Return errors as readable text rather than stack traces, so an unfamiliar agent can self-correct.

Keep the surface small. A server exposing forty tools will crowd out every other server the user has connected, and tool selection accuracy degrades for all of them.

Debugging connections

When a server does not appear, the cause is usually mundane: the process failed to start, the path in the configuration is wrong, or a dependency is missing. Because stdio servers communicate over standard output, anything your server prints for logging corrupts the protocol stream.

Log to stderr or a file, never stdout. That single mistake accounts for a large share of "my server connects then immediately disconnects" reports.

Local versus remote, practically

Local stdio servers are the default for developer tooling: no network, no auth, and they inherit the permissions of whoever launched them. That last point is a double edge — convenient, and a broad grant.

Remote servers make sense for shared infrastructure several people use, at the cost of everything that comes with running a service: authentication, authorisation, rate limiting and audit logging. Choose remote when the capability genuinely belongs to a team rather than a machine.

The honest summary

MCP is plumbing, and good plumbing is valuable. It makes integrations portable and turns a combinatorial problem into a linear one. It does not change what agents are capable of — that still comes down to the model, your tool design, and the constraints you impose.