MCP Standardizes Agent Access. The Hard Part Is Governance.

For builders, founders, and infrastructure teams, MCP is attractive for one reason: it can turn a pile of one-off agent integrations into a shared, reusable interface for data and tools. That matters when you want an AI agent to work across Slack, GitHub, internal databases, or web data without rewriting the plumbing each time. But once an agent can touch real systems, the question stops being “can we connect this?” and becomes “who can it see, what can it do, and how do we prove it behaved?” ^{1, 2}

Model Context Protocol, or MCP, is a standardized way for LLM applications to connect to external data sources and tools. Anthropic introduced it as a “universal, open standard” meant to replace fragmented integrations with a single protocol. ¹ The protocol’s promise is straightforward: make agent access portable and predictable without forcing every team to build a custom adapter for every system.

What MCP standardizes

MCP’s basic architecture is a client-server model. Hosts like Claude Desktop connect through clients to servers that expose tools, resources, and prompts. Resources supply context, tools execute actions, and prompts package reusable workflows. ^{2, 3}

That separation is what makes MCP useful. Instead of teaching the agent each target system’s API shape or query language, teams can wrap the underlying system behind a common interface. AWS describes MCP servers as wrapping “diverse systems behind a uniform interface for tool discovery, invocation, and response handling.” ⁴ The same server can then be reused across multiple clients, which is why the protocol is attractive to teams building for Claude, Cursor, or other MCP-aware surfaces. ^{1, 5}

The latest spec also makes the protocol feel more like infrastructure than a one-off integration pattern. MCP is built on JSON-RPC 2.0, uses a stateless request model, and supports version negotiation so clients and servers can handle compatible protocol versions without breaking interoperability. ^{6, 7, 8} That matters for builders because it reduces the hidden coupling that usually makes custom integrations brittle over time.

Why the protocol is spreading

The strongest adoption signal is not hype; it is reuse. A recent software-industry survey found nearly half of respondents rank MCP adoption as a top-five priority, with teams using it for test generation, code review, and debugging. ⁹ Another large study of MCP publications and repositories found the ecosystem expanded rapidly through 2025 and into early 2026, with most activity using MCP as an enabling layer rather than a topic of protocol research. ¹⁰

The practical pattern shows up in company architecture too. Supabase, as summarized in 1 Minute Signal coverage of David Ondrej, is shifting toward programmatic access through CLI, API, and MCP rather than treating the web dashboard as the main interface. That is a useful signpost for where MCP fits: not just as a developer convenience, but as part of an agent-ready product surface. ¹¹

Uber’s use case is even more concrete. In 1 Minute Signal coverage of The Pragmatic Engineer, Uber has used an MCP gateway since April 2025 to autogenerate tool specs from internal API metadata and let agents interact with internal services and vendor tools like Slack and Jira. The point is not that every team needs Uber-scale infrastructure. It is that MCP becomes compelling once a company wants the same authenticated tool surface to serve both humans and agents. ¹²

"Since April 2025, Uber has utilized an MCP (Model Context Protocol) gateway to autogenerate tool specs from internal API metadata, allowing agents to directly interact with internal services and vendor tools like Slack and Jira."

— 1 Minute Signal coverage of The Pragmatic Engineer ¹²

The catch: standardization is not governance

This is where most explanations get too optimistic.

MCP standardizes how agents discover and invoke tools. It does not, by itself, decide who gets access, what data can leave a network, or how to constrain a mistake once an agent starts acting on live systems. Frends is blunt about that distinction: MCP is “a protocol, not a platform.” ¹³ Official spec language points in the same direction, warning that MCP enables arbitrary data access and code execution paths, which creates security and trust obligations for implementors. ²

That is why governance becomes the deciding factor. Security teams need identity checks, role-based filtering, audit logs, rate limits, and sensible routing boundaries around the protocol itself. AWS guidance also recommends scoping tools carefully, bundling common operations into single calls, and writing tool descriptions that clearly explain purpose, parameters, and failure conditions. ¹⁴ Those are not niceties. They are how you keep the protocol from becoming a wide-open agent escape hatch.

The latest spec also raises the bar on implementation details. MCP is now stateless, supports server discovery, and uses standardized observability and versioning patterns so deployments can scale without session affinity or hidden protocol state. ^{7, 8} That makes the protocol easier to run, but it also shifts more responsibility to the server: ownership checks, authorization, and safe retries must be enforced where the data lives.

"MCP is a protocol, not a platform. It standardizes the interface between AI agents and tools, but it does not govern who can call what, what data can leave the network or what happens when the agent does something unexpected."

— Frends ¹³

Where MCP should stop

Not every integration belongs behind MCP.

One useful counterpoint comes from Adyen’s engineering perspective in 1 Minute Signal coverage of Beyond Coding. There, Mat Jones argues that MCP should be limited to exploratory work, while deterministic operations are better served by dedicated APIs or CLI tools. The concern is tool bloat: if a workflow is stable, narrow, and latency-sensitive, standardization may add more friction than it removes. ¹⁵

That is the right disagreement to surface. MCP is excellent when you want cross-client portability and a reusable server surface. It is less attractive when you need tight per-turn control over a single agent, very low latency, or a tool that changes too often to justify a long-lived protocol contract. ^{5, 16, 17}

There is also a strong “do not over-generalize” signal in the ecosystem data. A measurement study found the MCP ecosystem is sizable but fragile, with many placeholder or abandoned projects. ¹⁸ In other words, the protocol is real and growing, but maturity is uneven. That is a reason to use it deliberately, not a reason to assume every MCP server is production-ready.

What the ecosystem is converging on

The most useful MCP servers tend to cluster around a few repeatable jobs: computer and web automation, software engineering, and database/search access. ¹⁹ Those categories make sense because they sit at the center of agent workflows: retrieve context, reason over it, then take action.

That action step is getting more important. A large study of 177,436 MCP tools found that action-oriented tools grew sharply over time, including tools that modify external environments rather than just reading from them. ²⁰ That is the real operational shift. MCP is no longer just about letting an agent inspect data. It is becoming a standard way to let agents do things with that data.

And that is exactly why governance matters more as adoption rises. Security and access control remain among the leading barriers to MCP deployment, and survey data shows builders are still wrestling with authentication, authorization, and operational controls. ^{21, 22} The protocol is making agent access easier to standardize; the hard part is making that standardization safe enough for real systems.

What builders should do with MCP

If you are building with agents, treat MCP as an interface strategy, not a complete product strategy.

Use MCP when you need:

• reusable access to multiple systems,
• portability across more than one client,
• a clean boundary between agent logic and backend systems,
• and a way to avoid writing bespoke connectors for every integration. ^{1, 4, 5}

Be cautious when:

• the workflow is narrow and changes often,
• latency or determinism is critical,
• the data is sensitive enough to require explicit governance,
• or your team has not yet built auth, audit, and rate-limiting around the protocol. ^{8, 13, 14}

The most durable implementations will probably not be “MCP everywhere.” They will be a mix: MCP for reusable discovery and access, plus narrower APIs or hardened operational paths where the stakes are higher. That is a more boring answer than a universal standard. It is also closer to how real teams are already using the protocol.

The versioning model points in the same direction. MCP’s spec only increments protocol version when changes are backward-incompatible, and deprecated features remain available for a defined period. ⁷ That is a sign of a protocol trying to stay stable enough for production use without pretending the ecosystem is finished.

The builders who win with MCP will not be the ones who expose the most tools. They will be the ones who expose the right tools, with the right permissions, and enough observability to know what the agent actually did.