What MCP actually solves

Function calling already lets a model use a tool. So the reasonable first reaction to MCP is: what's the protocol for?

The answer isn't about capability. It's about how many integrations you have to write.

The combinatorial problem

Without a shared protocol, every AI application that wants to reach every data source writes its own connector. Four applications and five systems is twenty integrations, each with its own auth handling, schema conventions, and error semantics. Add one system and you write four more.

A protocol collapses that. The system exposes itself once as a server; any compliant client can use it. You go from a multiplication to an addition — the same trick that made language servers work for editors, and for the same reason.

What it standardises

Three things, and it's worth separating them because people tend to collapse them into "tools":

• Tools — actions the model can invoke, with described inputs. The familiar part.
• Resources — readable context the client can pull in, which is a different shape from an action and has different caching and permission implications.
• Prompts — reusable interaction templates a server can offer, so the system exposing the data can also suggest how to use it well.

That third one is the most overlooked. The team that owns a system usually knows better than the application developer how it should be queried.

What it doesn't solve

MCP doesn't decide which tools an agent should have, and that's still the hard design question. An agent with forty available tools tends to perform worse than one with six, because tool selection is itself a reasoning task competing for the same attention.

It also doesn't solve authorisation in any deep sense. A protocol can carry credentials; it can't tell you whether this agent, acting for this user, should be allowed this action right now. That stays your problem, and it's the one most likely to bite in production.