What problem does MCP solve?

MCP solves the N×M problem. With no common protocol, every AI application needs its own connector for every external system: N applications times M systems gives N×M integrations to write, test and maintain. With a protocol, each application writes one client and each system writes one server. That is N+M.

This arithmetic is the entire case for the Model Context Protocol, and it is not a new one. It is the same sum that produced USB in 1996 and the Language Server Protocol in 2016, with the same wins and the same caveats.

What usually goes unsaid is that the volume of code is almost never the problem. What N×M really counts is the number of bilateral agreements: every application-system pair settles error shapes, authentication, pagination and field names on its own. That is why comparing MCP to a REST API answers a different question, and why plugins and GPTs went after this same problem and stopped halfway.

The arithmetic, and where it lies

Four applications and five systems come to twenty connectors. With a protocol, four clients plus five servers come to nine implementations. Ten by ten would be a hundred against twenty.

The exact point where the trade starts paying falls out of the arithmetic itself. N×M exceeds N+M from two applications and two systems onward: at 2×2 both sides tie at four, and every larger combination favours the protocol. Hold on to that number, because it is the ceiling of the argument rather than the floor. It is the best case, the one where every connector costs the same.

And that is where the arithmetic lies. It assumes the twenty integrations are twenty independent jobs, and inside a single company they never are. If the four applications and the five systems share an owner, the second connector reuses the first, the third reuses both, and what you end up with is an internal library playing exactly the role of the protocol — for free, with no extra process and no JSON-RPC in the middle.

The N×M problem is only real when the two populations have different owners. Then there is no shared library to write, because there is no shared repository. Every pair becomes a negotiation: who handles the 429, what happens when the token expires, which field is the stable identifier. A 2025 survey of agent interoperability protocols framed this as the reason the whole category exists: ad-hoc integrations are hard to scale, secure and generalize across domains¹.

It helps to see this concretely. A ticketing system paginates by cursor; the support team’s agent expects offset and limit. The system returns permission failures as an HTTP 403 with an empty body; the agent needs to know whether to ask the user for credentials or give up. The identifier shown in the UI is the ticket number, but the stable one is an internal UUID. None of those three decisions is hard. All three have to be made again, from scratch, by every application that connects to that system, because there is nowhere to write the answer down once. That “again, from scratch” is what N×M measures.

Saving code is the side effect. Saving coordination is the product.

The same pattern, three times

USB 1.0 was published on 15 January 1996 by a consortium that included Intel, Microsoft, IBM and Compaq. Before it, each class of peripheral had its own physical port: serial for modems, PS/2 for keyboards and mice, ADB on the Macintosh, SCSI for storage. Shipping a new device meant picking a port to plug into and writing a driver per operating system. USB did not make the driver go away. It moved who owns the driver: the mouse manufacturer ships one device, not one device per computer.

The Language Server Protocol is the closest case to MCP, and the most instructive. Before it, offering completion, go-to-definition and diagnostics for language L inside editor E required a plugin specific to that pair. Microsoft, Red Hat and Codenvy announced their collaboration around the protocol on 27 June 2016². A 2025 paper on generating language servers puts the effect in exactly the notation that matters here: LSP reduces the L×E language-editor combinations to L+E, with a single language server talking to editors through protocol plugins³.

MCP repeats the design in November 2024, with one difference in vocabulary. In LSP the server is the language and the client is the editor. In MCP the server is the system and the client is the AI application. The structure is the same: JSON-RPC, a discovery step for what exists on the other side, and a closed set of operations.

That same 2025 paper carries the caveat that rarely shows up when someone cites LSP as a success story. Almost ten years on, overlapping implementations of linguistic components are still a problem: each language server rewrites its own type system, its own parser and its own name resolution, and that duplication is precisely what the authors attack by generating servers from a modular description³. The protocol standardized the conversation between the two ends and standardized nothing about what happens behind either one.

Expect the same of MCP. The protocol says how to list and call a tool. It says nothing about how your server paginates results, what it does when the database is down, or how it decides that ten lines of log are enough.

What the protocol actually standardizes

It pays to be specific here, because the gap between what is in the spec and what is not is where expectations break.

Revision 2026-07-28 fixes the message envelope as JSON-RPC 2.0, the discovery call (server/discover), the listing and invocation format for the three primitives, argument description in JSON Schema, and two standard transports⁴. That is enough for a client that has never seen your server to find out what it does and invoke a tool with valid arguments.

Everything that is genuinely hard sits outside the spec: the right granularity for a tool, what to name it, what each error in your domain means, how you rate limit per user, how you map permissions in the source system onto whoever is on the other end of the conversation. A 2025 study that mapped the life cycle of an MCP server into four phases shows the size of that residue: creation, distribution, installation and operation, each with decisions the protocol does not make for you⁵.

MCP’s honest promise is a narrow one. It swaps N×M plumbing implementations for N+M plumbing implementations. The domain logic stays at N or M, depending on which side of the wire you are standing on.

Where the N×M argument breaks

N equals 1. With one agent and one API, the protocol is pure cost: another process, another transport, another message format, and no reuse on the far side. 1×M against 1+M never favours the protocol. The gain only appears once a second consumer exists, and it has to be a real one rather than a hypothetical.

M is smaller than it looks. The popular argument for MCP is the size of the catalogue of ready-made servers. A 2025 measurement crawled six marketplaces for 14 days, collected 17,630 entries and validated 8,401 projects, of which 8,060 servers and 341 clients. More than half of what was listed was invalid or low-value, and the authors recorded dependency monocultures and uneven maintenance among the rest⁶. Effective M, the servers you would actually run in production, is a fraction of advertised M.

The sum carries a cost the product did not. Every tool a server advertises takes up room in the model’s context, on every call. Connecting servers because they exist converts an engineering win into a precision loss: the model starts choosing among dozens of similar-looking tools. Under N×M each application only ever carried what it had deliberately integrated.

The protocol moves, and now everyone moves together. This is the least discussed side effect of centralizing on one contract. Under N×M each pair migrated on its own schedule and a change broke one integration. Under N+M, a spec revision touches N+M implementations at once. Revision 2026-07-28 removed the initialize handshake and transport sessions, and it is the fifth revision in twenty months⁴. What you saved in connectors, you now pay in spec watching.

A shared surface shares its risk too. A tool’s description enters the model’s context and steers what it decides to do. Under N×M, one malicious integration affected one pair. Under N+M, a popular server reaches every client that installed it. The 2025 threat mapping of the MCP server life cycle exists because of that concentration⁵.

What the trade costs

There is no trustworthy market number here, so it is worth looking at the shape of the cost rather than its magnitude.

For whoever exposes a system, an MCP server is a wrapper: you already have the API, and the server translates between it and the protocol. The real cost is not writing the first version, it is carrying the decisions the spec declines to make — tool granularity, the wording of descriptions, error handling the model can actually use to correct itself.

For whoever consumes, the recurring cost is context. A modest tool declaration, with a name, a description and a schema, lands in the hundreds of tokens, and it is resent on every model call rather than once per session. Measure yours with your provider’s token-counting endpoint before deciding how many servers stay connected. It is the only part of this bill you can measure precisely.

The third cost is the one most teams meet later: staying compatible with more than one protocol revision while the ecosystem migrates. In July 2026, with 2026-07-28 freshly published and most installed servers still speaking earlier revisions, that cost is current rather than theoretical.

When it is worth it

1. Count real consumers, not possible ones. If there is one today, write direct function calling and move on. Migrating to MCP later is mechanical; anticipating it is what gets expensive.
2. Check whether the two populations have different owners. If they are all yours, an internal library delivers the same N+M with no protocol, no extra process and no external versioning.
3. Treat the public catalogue as raw material, not inventory. Half of what is listed never got past prototype. Read the code of any server you intend to install, especially the tools that write somewhere.
4. Pick granularity before writing the first tool. Thirty thin tools and five fat ones solve the same problem at very different context costs, and the protocol has no opinion on the matter.
5. Pin the protocol revision you support and put it in the README. Under N+M that is the single piece of information that prevents the most likely integration bug of the coming months.

Step 2 is the one most teams skip. N×M is an organizational boundary problem dressed up as an architecture problem, and anyone without the boundary pays for the protocol without receiving what it came to sell.

Footnotes

1. Ehtesham et al. (2025) compare four agent interoperability protocols and state the motivation common to all of them: ad-hoc integrations are hard to scale, secure and generalize across domains. ↩

2. The joint Red Hat, Codenvy and Microsoft announcement of 27 June 2016 is the source for the LSP standardization date used here. ↩

3. Bruzzone et al. (2025) describe LSP’s effect as reducing language-editor combinations from L×E to L+E, and record that overlapping implementations of linguistic components remain a problem almost ten years later. ↩ ↩²

4. Revision 2026-07-28 of the specification is the source for what the protocol fixes, for the removal of the initialize handshake and for the revision count. Verified on 30 July 2026. ↩ ↩²

5. Hou et al. (2025) decomposed the life cycle of an MCP server into four phases and derived a threat taxonomy from it. ↩ ↩²

6. Guo et al. (2025) crawled six MCP server marketplaces over 14 days, collected 17,630 entries and validated 8,401 projects, with more than half of the catalogue classified as invalid or low-value. ↩