Every agent eventually needs to touch a system you didn’t write. The protocol that makes that cheap is starting to matter more than the agent.
The most boring connector in my bag is becoming the most important standard in the agent ecosystem, and nobody is paying attention to the right part of it.
Most people read MCP, the Model Context Protocol, as Anthropic’s way to let Claude Code reach external tools. That was true once. It is not the reason MCP matters now. The reason is that MCP has stopped being a Claude feature and started being the thing every runtime, every framework, and every vendor ships as their default answer to one question. When your agent needs to call something you did not write, how does it discover the tool, and how does the tool talk back.
That is the question the whole agent field has been papering over with glue code for two years. MCP is the first answer that looks likely to stick.
The protocol started as Anthropic’s announcement in November 2024. In the two years since, it added a spec repository at 9,023 stars, official Python and TypeScript SDKs at 24,086 and 13,223 stars, a reference servers repository at 89,769 stars, and a community registry at 7,184 stars. Those numbers are not the point, but they are the evidence that the point is real. This is not a corporate SDK dressed up as open. It is an open protocol that happens to have a corporate patron, which is a material distinction in an ecosystem drowning in vendor APIs pretending to be standards.
What makes the protocol useful is that it is genuinely small. The core is a list of tools, each with a name, a description, and a schema for its inputs. A server advertises its tools. A client discovers them. The model picks a tool, the client invokes it, the server returns a structured result. There is no session to maintain, no state to reconcile, no long-lived connection to babysit. After the July 28 specification, which finalized what people are calling MCP 2.0, there is also no initialize handshake. A single HTTP request can call a single tool and get a result back. Session state is gone.
That statelessness is the detail that separates a protocol from a framework. Simon Willison spent 2025 warning about MCP’s prompt injection hazards and arguing that an agent with shell access and curl could do everything the protocol could. He changed his position after the 2.0 spec, and his reasoning is the clearest articulation of why MCP crossed from interesting to default. A purpose-built, auditable MCP tool is harder to attack than an agent armed with arbitrary shell access. Smaller models on a laptop can drive a constrained tool interface that they would struggle to drive as an open-ended shell. The thing that looked like a limitation, the smallness, turned out to be the safety property.
That is the shift I want to bracket this week, because it is bigger than any one tool. We spent August so far on runtimes and desktops, on where the agent runs and whether it survives a restart. This week is about the layer under the agent. The layer that decides what the agent is allowed to reach.
The USB-C comparison is apt in one way and misleading in another, and the misleading part is where the real argument lives. USB-C is a physical standard that solved a port problem. You plug a device in, it enumerates, it works, you do not think about the chipset. MCP is doing the same thing for tool access. Hardcode five integrations and it works fine. Hardcode fifty and the tool descriptions eat your context window, the model gets worse at choosing the right tool, and every new integration is a week of maintenance you will not schedule until it breaks. A protocol that lets tools be discovered at runtime, filtered to relevance, and invoked by schema flips that balance. One MCP server, any MCP-compatible client. One client, any server. That is the port story, and it is real.
The misleading part is that standards do not become standards because they are elegant. They become standards when the people who would rather not standardize are forced to anyway. MCP is at exactly that inflection point, and you can read it in who is adopting it, not in how well it is specified. OpenAI announced it will support MCP across its product line, a decision that reads as tactical but has structural consequences. Microsoft built it into the Agent Framework we covered last week. Google’s A2A protocol handles agent to agent communication while MCP handles agent to tool, and even Google treats the two as complementary rather than competing. Block’s Goose and the Linux Foundation’s BeeAI both ship MCP as their tool layer by default. When the leaders who would each prefer to own the standard all ship the same one, the standard has won by surrender.
That is how USB-C actually happened, despite every vendor preferring a proprietary port. Enough players built it in, and the alternative stopped being viable. Nothing about MCP is legislated. It is winning the way it has to, which is by being the thing nobody can justify not shipping.
Here is the part I will spend the week on, because it is the part the marketing skips.
A protocol that makes tools discoverable does not make them safe, and it does not make them trustworthy. The hard problems in the tool middleware layer are not discovery. They are three things that live underneath it, and MCP does not solve any of them, which is worth stating plainly even as I make the case that MCP matters.
The first is authentication at agent scale. Every API your agent calls needs credentials, and every credential is a boundary that needs rotation, least-privilege scoping, and an audit trail for what was called and why. We covered the credential tools in July, Infisical Agent Vault and Harbor SDK, which solve the narrow problem of giving an agent access without giving it the keys. But there is no standard for agent-level OAuth that does not eventually require a human to click allow again. The discovery layer gets tools into your agent. The auth layer decides whether they stay. MCP has nothing to say about it.
The second is that an MCP server runs as a subprocess with the permissions of whatever started it, which on a desktop is everything. Goose’s own documentation is honest about this. A malicious or buggy MCP server can touch anything the host agent can. The protocol does not sandbox, does not constrain what a server is allowed to advertise, and does not help you tell the difference between a quality server and a community one with two stars and no recent commits. The trust problem got more people to adopt MCP. The trust problem is also the thing that will get people burned once the registry fills with servers nobody vetted.
The third is that tool descriptions are prompt injection surfaces. The model reads the description, then acts on it. A hostile tool can embed instructions in its own description, and a naive agent will follow them. This is not hypothetical. It is the documented failure mode of every tool-use system, and MCP’s schema-first design makes it easier to reason about, not harder. The mitigation belongs in the runtime layer, in how tools are filtered and how the model’s choices are validated, not in the protocol.
None of that is an argument against MCP. It is an argument against the version of MCP the launch posts keep describing, the one where you drop in a registry and everything just works. The protocol is the connector. The security model, the credential lifecycle, the governance of which agents may touch which APIs, those are the layers above and below it, and they are still unsolved. This week’s posts spend most of their time on those unsolved layers precisely because the discovery problem is, for the first time, basically solved.
What changes in how we build when the connector standardizes is the part I find genuinely exciting, and it is not the part the vendors lead with.
When tools are hardcoded, the agent and the integration ship together. You cannot use someone else’s Slack integration without rewriting your agent around it, and you cannot replace your agent without throwing away the integrations. MCP decouples those two things. The agent is a loop and a policy. The tools are a catalog of servers. Swap the model, swap the runtime, keep the tools. Swap a tool, keep the agent. The boundary that used to be a rewrite becomes an interface. That is the actual promise of the USB-C story, and it is a real promise, not a slide deck.
It changes where the value accumulates too. For the past two years the field has treated agent frameworks as the moat. Build the best framework, own the developers. But frameworks are commoditizing, which is a statement August has been making in every arc so far. Runtimes are where persistence and recovery live, and tools are where the actual work gets done. If the tools are interoperable, the moat shifts from the framework to the catalog of capabilities the agent can reach, and the governance layer that decides what it may touch. The interesting acquisition targets over the next year are not going to be the framework companies. They are going to be the tool catalogs and the credential brokers, because those are the layers the connector standard made valuable by making portable.
Tomorrow I will put a name on the tool catalog side of this. Composio is the project that wants to be the npm of agent capabilities, 250-plus pre-built integrations with managed authentication, and it captures both the promise and the early-stage reality of the tool registry as a product. Then AWS Strands, Amazon’s quieter bet that tool middleware is a layer worth standardizing around. Then the authentication problem that MCP refuses to solve, and then a reference architecture for the whole stack, from discovery down to the credential the agent never sees.
If you are building an agent today, the decision you are actually making is not whether to use MCP. The ecosystem already ships it. The decision is whether you treat your tools as a catalog you compose and govern, or as a pile of one-off integrations you will be maintaining long after the model upgrade made the rest of the stack feel modern.
The connector is settled. The security model is not. That is the interesting part.
If this was useful, forward it to one engineer who needs less noise in their feed.