← ALL POSTS
MCPAIAgentsInfrastructureDevOpsEngineering

MCP and Agentic AI Have Crossed the Infrastructure Threshold

MCP has 97 million monthly SDK downloads, governance under the Linux Foundation, and first-class support from every major AI vendor. That is not a popular open-source project. That is infrastructure. Here is what that transition actually changes for developers building AI systems.

April 3, 202617 min read

MCP and Agentic AI Have Crossed the Infrastructure Threshold

The question used to be "should we adopt MCP?" That question is now closed. The right question is "are we treating MCP with the operational seriousness that infrastructure demands?"

In December 2025, Anthropic donated the Model Context Protocol to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI — with backing from Google, Microsoft, AWS, Cloudflare, and Bloomberg. That move is a specific kind of signal. It is the same move Kubernetes made when it was donated to the CNCF in 2016. It is what npm did when it joined the OpenJS Foundation. It is the thing that happens when a tool stops being a project and starts being infrastructure.

This post assumes you already know what MCP is and when to reach for it — that is covered in Why Would I Use an MCP Server?. What this post is about is what changes when a protocol graduates from "widely used open-source tool" to "infrastructure." The answer is: quite a lot.

Table of Contents

  1. The infrastructure threshold
  2. Why the Linux Foundation move is the clearest signal yet
  3. What 97 million downloads and 10,000 servers actually mean
  4. The agentic stack is consolidating
  5. What changes when something becomes infrastructure
  6. Production-grade MCP: what it looks like in practice
  7. The risk surface expands with the adoption surface

The Infrastructure Threshold

"Infrastructure" is a specific claim. It does not mean "popular" or "well-maintained" or even "widely deployed." Plenty of tools hit those marks without ever becoming infrastructure. Infrastructure has a narrower definition:

It is the thing that other things are built on top of, without thinking about it.

When HTTP became infrastructure, you stopped debating whether to use it and started assuming it. When TCP/IP became infrastructure, the question was not "should my application use TCP/IP" — it was "what does my application do over TCP/IP." Infrastructure is what lives below the layer where decisions are made.

Three conditions mark the transition:

  1. Governance neutrality. A tool that one company controls is a product or a platform. Infrastructure cannot be owned by a single vendor because no one builds critical dependencies on something a competitor can sunset. Governance neutrality — independent foundations, open specifications, multi-vendor steering — is the mechanism that makes infrastructure safe to depend on.

  2. Multi-vendor adoption. When your competitors are integrating the same protocol into their flagship products, the protocol has ceased to be an advantage for anyone and started being a cost of not supporting it. Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code all have first-class MCP client support. At that point, MCP support is not a differentiator — it is table stakes.

  3. Embedding in the build/deploy/run stack of non-AI companies. The surest sign that something has become infrastructure is when organizations that are not in the AI business start treating it as a dependency. When an enterprise's SOC 2 audit scope starts including MCP servers, and when cloud providers start offering managed MCP services, the protocol has moved from the AI ecosystem into the enterprise operations layer.

MCP has crossed all three thresholds. That is not a prediction. It happened in December 2025.

Why the Linux Foundation Move Is the Clearest Signal Yet

Anthropic's donation of MCP to the AAIF is important not because foundations are particularly interesting, but because of what it signals about what Anthropic believes MCP's trajectory to be.

You do not donate a protocol to a neutral foundation if you expect it to be a passing experiment. You donate it when you believe the protocol will become load-bearing infrastructure, and you recognize that load-bearing infrastructure cannot be owned by one company without creating a structural risk for everyone who builds on it.

The Kubernetes parallel is precise. Kubernetes was an internal Google project. Google donated it to the CNCF in 2016. Before that donation, every enterprise evaluating Kubernetes had a reasonable question: "Is this just Google's internal tool that they open-sourced? Will it stay aligned with our needs if it stays under Google's control?" The CNCF donation answered that question permanently. The debate about Kubernetes being a Google product ended on the day of the donation. Within three years of the donation, Kubernetes had become the de facto standard for container orchestration.

The AAIF donation does the same thing for MCP. The debate about whether MCP is "Anthropic's protocol" ended in December 2025.

But there is a detail in the AAIF structure that matters more than the foundation itself: OpenAI is a co-founder. Not a supporting member. A co-founder.

OpenAI and Anthropic compete in the AI model market as directly as any two companies in the industry. The fact that OpenAI co-founded the governance structure for a protocol that Anthropic originally designed is not a diplomatic gesture. It is a statement that OpenAI views MCP as critical enough to the emerging agentic ecosystem that they want a seat at the table governing it — and that they are not trying to fork it or replace it with their own competing standard.

That is the tell. You do not co-found neutral governance for a tool you think is temporary, or for a tool you plan to marginalize. You co-found it when you believe the protocol is going to be infrastructure, and you want influence over how it evolves.

What 97 Million Downloads and 10,000 Servers Actually Mean

97 million monthly SDK downloads. 10,000+ published MCP servers. First-class client support in every major LLM product.

These numbers are not interesting because they are large. They are interesting because of what they indicate about where adoption is happening.

Developer playground numbers look different. They tend to be front-loaded: high early spike, long tail of abandonment. The 97 million monthly figure is not a spike — it is a rate. Monthly downloads are a measure of ongoing active use, not initial interest. At that rate, with that server count, MCP is being wired into pipelines that run continuously. Production systems.

The comparison points that matter here are npm around 2014 and Docker Hub around 2015. Both were already widely used by developers before those dates. What happened at those inflection points was not that developer adoption spiked — it was that enterprise adoption caught up. Large organizations with slow procurement cycles started including npm and Docker in their standard platform tooling. The tools stopped being "what developers use to build" and started being "what we deploy to production."

That inflection is where MCP is now. 10,000 published servers is not a developer experiment — it is the shape of an ecosystem that is producing artifacts at the rate of a standard being wired into enterprise pipelines. Tool authors publishing MCP servers for their libraries is already beginning to look like what happened with type definition packages after TypeScript became widespread: an expected, default artifact that you ship alongside the primary package.

Within the next 18 months, publishing an MCP server for your developer tool or internal platform will carry the same expectation weight as publishing API documentation. It will not be optional for tools that want serious enterprise adoption.

The Agentic Stack Is Consolidating

MCP did not get donated to the AAIF alone. It joined Block's goose (an open-source agentic framework) and OpenAI's AGENTS.md (a specification for defining agent behavioral contracts) in the same foundation.

That grouping is not coincidental. Read it as a layer diagram:

These are not competing tools. They are layers. The fact that all three are being governed under the same foundation is the governance side of a technical decision: this is intended to be the agentic equivalent of the POSIX standard. A set of interoperating primitives that different implementations can conform to, enabling agents from different vendors and frameworks to compose reliably.

POSIX is a useful comparison because it captures what good infrastructure standardization looks like. POSIX did not eliminate diversity — you still had AIX, Solaris, HP-UX, and later Linux, all with distinct implementations and trade-offs. What POSIX did was create a guaranteed baseline that application code could target without caring which underlying system it ran on. The AAIF primitives are pursuing the same outcome for agentic AI: a baseline that multi-agent systems can rely on regardless of which model, framework, or runtime is doing the orchestration.

The implications for framework diversity are the same as POSIX: frameworks will proliferate, but the interoperability layer below them will consolidate. If you are evaluating agent frameworks today, the relevant question is not just "which framework is best" but "which frameworks commit to MCP/AGENTS.md compliance as a floor."

What Changes When Something Becomes Infrastructure

When HTTP became infrastructure, developers stopped thinking about it and started building on it. That shift had concrete consequences. It is worth mapping the equivalent consequences for MCP.

You will not choose whether to support MCP. Enterprise procurement increasingly includes integration requirements. Organizations that have standardized on MCP-compatible tooling (and with Claude, ChatGPT, and Copilot all supporting it, many already have) will specify MCP compatibility as a vendor requirement. This is already happening in RFPs for AI tooling. The decision will be made by your sales cycle, not your engineering roadmap.

Security posture shifts from "nice to have" to "audit target." An MCP server that sits between an LLM and your production database is not a developer tool. It is a system that processes external input (model-generated tool calls) and executes privileged operations (database queries, API calls, file reads). That makes it audit scope. SOC 2 and ISO 27001 audits will include MCP servers as part of the access control and change management review. If you are treating your MCP servers as scripts rather than services, that gap will surface in your next audit.

Breaking changes become politically expensive. Infrastructure has a different versioning contract than libraries. When you break a library's API, you inconvenience developers. When you break an infrastructure component's interface, you break production systems at companies that cannot tolerate that. MCP servers that are in production use will need semantic versioning, deprecation windows, and changelogs — not because it is good practice, but because the downstream cost of a breaking change will be someone else's incident.

Cloud providers will offer managed MCP services. Cloudflare already has a positioning play here with Workers and their AI gateway layer. AWS, GCP, and Azure will follow. Managed MCP infrastructure — where you deploy a server definition and the cloud provider handles the runtime, scaling, authentication, and observability — is a natural extension of the managed function and API gateway products these providers already offer. Plan your MCP architecture with that future in mind: clean separation between the tool logic and the transport/hosting layer will make migration straightforward.

Tool authors will publish MCP servers as a default artifact. The trajectory is clear from the 10,000 server count. Publishing an MCP server for your developer tool, data product, or internal platform will become the expected norm in the same way that publishing a REST API or a CLI became expected norms for software that wants to be composed into other systems. Library maintainers will publish MCP servers the way they publish type definitions — as a default, expected delivery artifact, not an optional extra.

Production-Grade MCP: What It Looks Like in Practice

Demo-quality MCP servers are everywhere. Production-grade ones are not, yet — but infrastructure-level adoption means the gap will be expensive.

The minimal differences between a demo implementation and a production one are: structured logging, versioning, proper error surfaces, and rate limiting. Here is a concise Python example showing what that baseline looks like:

import logging
import time
from typing import Any
from mcp.server.fastmcp import FastMCP

logger = logging.getLogger(__name__)

mcp = FastMCP(
    name="internal-db-mcp",
    version="1.2.0",
)

# Rate limiting state (in production: use Redis, not in-memory)
_request_counts: dict[str, list[float]] = {}
RATE_LIMIT = 60  # requests per minute per caller

def _check_rate_limit(caller_id: str) -> bool:
    now = time.time()
    window_start = now - 60
    calls = _request_counts.get(caller_id, [])
    calls = [t for t in calls if t > window_start]
    _request_counts[caller_id] = calls
    if len(calls) >= RATE_LIMIT:
        return False
    _request_counts[caller_id].append(now)
    return True

@mcp.tool()
def query_users(
    filter_active: bool = True,
    limit: int = 100,
    caller_id: str = "unknown",
) -> list[dict[str, Any]]:
    """
    Return user records. Read-only. Enforce limit <= 500.
    
    Args:
        filter_active: If True, return only active users.
        limit: Maximum number of records to return (capped at 500).
        caller_id: Identifier for rate limiting and audit logging.
    """
    if not _check_rate_limit(caller_id):
        logger.warning("rate_limit_exceeded caller=%s", caller_id)
        raise ValueError(f"Rate limit exceeded for caller: {caller_id}")

    limit = min(limit, 500)  # hard cap regardless of what the model requests

    logger.info(
        "tool_call name=query_users caller=%s filter_active=%s limit=%d",
        caller_id, filter_active, limit,
    )

    try:
        # db_conn is a read-only connection — enforced at the DB user level
        rows = db_conn.execute(
            "SELECT id, name, email, created_at FROM users WHERE active = %s LIMIT %s",
            (filter_active, limit),
        ).fetchall()
        logger.info("tool_success name=query_users rows_returned=%d", len(rows))
        return [dict(row) for row in rows]
    except Exception as exc:
        # Surface errors as structured log entries, not raw exceptions
        logger.error("tool_error name=query_users error=%s", str(exc))
        raise ValueError(f"Database query failed: {exc}") from exc

A few things this example enforces that demo implementations typically skip:

The version field in the server definition matters too. When you ship a new version of this server with a changed tool signature, consumers need a way to pin to a version until they are ready to update. Infrastructure without a versioning contract is not infrastructure — it is a shared footgun.

The Risk Surface Expands with the Adoption Surface

There is an uncomfortable corollary to MCP becoming infrastructure: the attack surface it represents grows proportionally.

An MCP server that has access to your database, your internal APIs, and your file system is not a toy. It is a privileged process that accepts LLM-generated instructions and executes them with real credentials against real systems. The fact that those instructions come from a model — rather than directly from a human — does not make the server less dangerous. In many respects it makes it more dangerous, because the model is a larger and more varied attack surface than a human operator.

Prompt injection through tool outputs is a known and real attack vector. A tool that reads from an external source (a web page, a customer email, a third-party API response) and returns that content to the model is potentially delivering attacker-controlled instructions to the model's context. If the model then calls a tool with those instructions — writes to a database, exfiltrates to an external URL, modifies a file — the MCP server is the execution layer for that attack.

The governance and security conversation around AI infrastructure is no longer abstract. As covered in the Two Leaks in Five Days post, Anthropic was privately briefing governments about AI cybersecurity risks at the same time its own operational security was failing. The risks are real, and the actors paying attention to them are increasingly well-resourced.

Treat your MCP servers with the same security posture you apply to any other internet-exposed service that holds privileged access:

This is not paranoia. This is the standard operational posture for infrastructure. The fact that the client is an LLM rather than a browser or a microservice does not change what the threat model looks like.

Key Takeaways

Sources

← BACK TO ALL POSTS