When Anthropic published the Model Context Protocol specification in late 2024, the immediate reaction in developer circles was roughly: "Oh, good - a standard way to connect tools to LLMs." That's accurate. It is that. But framing it as plumbing undersells what's interesting about the design choices it makes, and why those choices encode a particular set of opinions about what agentic AI should look like.

I've spent a few months building with MCP, evaluating MCP servers for this site, and thinking about why certain architectures feel right and others feel wrong. What I've come to believe is that MCP isn't just a connector format - it's a statement about how we should think about the boundary between language models and the systems they operate in.

The pre-MCP world

Before MCP, connecting an AI model to external capabilities was a DIY affair. Function calling existed - OpenAI introduced it to their early models in 2023, and Anthropic followed with tool use - but the implementation of "here's a function, here's how to call it, here's how to parse the result" was entirely up to each developer. This produced a proliferation of approaches, none compatible, all requiring custom integration work every time you wanted to combine capabilities from different providers.

The pragmatic result was that most production AI applications were highly bespoke: a model with a hand-written set of tools, specific to that application, maintained by that team. Reuse was hard. The ecosystem was fragmented. If you wanted to give your agent access to your company's internal knowledge base and also a web search tool and also a code execution environment, you were building three separate integrations.

What MCP actually standardizes

MCP standardizes the protocol by which a language model client can discover and invoke capabilities exposed by external servers. An MCP server exposes a set of tools, resources, and prompts. A client (an AI application, an agent harness, a developer tool) can connect to that server, discover what it offers, and call it in a standardized way.

This is, on the surface, a fairly conventional API design problem. You could imagine it being solved with REST endpoints and OpenAPI specs, or with gRPC and protobufs, or a dozen other approaches. What's interesting is what MCP chose to optimize for - and what that reveals about the design philosophy.

The spec is designed around capability discovery at runtime, not at compile time. An MCP client doesn't need to know in advance what tools a server exposes; it asks at connection time. This is a meaningful choice. It means the model can, in principle, connect to a new server and understand what it can do without the developer hard-coding that knowledge into the application. The ecosystem is meant to be composable in a way that static tool definitions are not.

"The interesting question isn't 'what can this agent do?' It's 'what should the agent be allowed to discover it can do, and when?'"

The theory of agency embedded in the spec

Here's what I mean by saying MCP encodes a theory of agents. The spec draws a clear line between the model and the world. The model reasons and decides; the MCP server acts. The model doesn't have direct access to file systems, databases, or APIs - it has access to tools that a server exposes, which can themselves have whatever permissions and guardrails are appropriate.

This is a principled separation of concerns. It means that the security model, the rate limiting, the access control, the audit logging - all of that lives in the server layer, not in the model layer. You can give a model access to a tool that reads from a database without giving it direct database credentials. You can scope what the model can see and do without modifying the model itself.

Compare this to an alternative design where the model has direct API keys and calls services directly. That design is simpler to build initially but terrible at scale: every model that touches your systems is a potential security surface, the blast radius of a compromised or misbehaving agent is much larger, and you have no consistent place to put governance controls.

MCP's design says, implicitly: agents should be powerful but bounded. They should be able to do a lot, but through sanctioned channels with clear interfaces, not through unmediated access to the world. This is the right opinion to have, and I'm glad it's baked into the protocol. The broader implications of bounded delegation - who bears responsibility when an agent operating within its permissions still causes harm - are the subject of Autonomy, delegation, and the question of who's responsible.

What building with it taught me

The more I've worked with MCP, the more I've found that it changes how I think about the architecture of software generally - not just AI software.

The MCP model, where capabilities are exposed as discrete, discoverable tools with clear input/output schemas, is a useful lens for thinking about any interface design. It forces you to be explicit about what a service can do, what data it requires, and what it returns. The AI agent as consumer makes visible a lot of design debt that traditional human-facing APIs can hide: ambiguous schemas, inconsistent error handling, side effects that aren't signaled in the interface.

Building a good MCP server, it turns out, is a pretty good proxy for building a good service interface generally. The act of asking "what tools should I expose, and what should each one require?" surfaces design questions that often get deferred in traditional development.

There's also something clarifying about the resource concept - the idea that servers expose not just callable tools but also readable data sources that the model can retrieve and reason over. This distinction between "things the model can do" and "things the model can know" maps onto a genuinely useful architectural separation in real systems.

The ecosystem question

None of this is useful if the ecosystem doesn't materialize. A standard that nobody adopts is just a document. But there are good reasons to think MCP has critical mass: Anthropic built it into Claude Desktop and their API; major developer tools (Cursor, Windsurf, VS Code via the Copilot extension) have adopted it; and the open-source community has produced a significant library of servers covering common use cases.

Our reviews cover the best MCP servers we've tested - the ones worth using in production. But beyond the individual server quality, what's notable is that the ecosystem exists at all. Eighteen months ago it didn't. The speed of adoption suggests that the developer community recognized a genuine need being addressed, not just a vendor trying to capture a standard.

Whether MCP ends up being the dominant standard for AI-tool integration long term, I genuinely don't know. Standards battles are unpredictable, and there are competing approaches. But the principles it embeds - capability discovery, clear model/world separation, server-side governance - seem robust enough that any winning design will probably end up looking similar.

For now, it's made me a better systems thinker. That's not nothing. If you're a developer thinking about how AI fits into your workflow more broadly, the AI for Software Engineers path is the map.