Is your MCP server actually safe to put in front of real AI agents?

Ninety-seven million. That's how many times the Model Context Protocol SDK was downloaded in a single month in March 2026. For context: React, the JavaScript framework that became the foundation of modern web development, took roughly three years to cross 100 million monthly downloads. The MCP SDK crossed it in under 18 months — growing from about 100,000 downloads at launch in late 2024 to 97 million today, a 970x increase. By May 2026, the official registry was tracking nearly 10,000 unique server records. Third-party catalogs were indexing closer to 20,000. Early 2026 surveys found that 28% of Fortune 500 companies had deployed MCP servers for production AI workflows.

So is the protocol actually production-ready? Or are we measuring momentum and calling it maturity?

Where does this data come from?

The deployment and growth figures draw on the official MCP Registry API (pulled May 24, 2026: 9,652 latest server records, 28,959 version records) and industry tracking of the combined Python and TypeScript SDK download counts. Authentication statistics come from a security audit of production MCP deployments published by Microsoft's Azure engineering team in mid-2026, covering thousands of public and enterprise servers. Vulnerability rates are from Equixly's offensive-security assessment covering late 2025 through early 2026, and BlueRock Security's SSRF analysis of 7,000+ public MCP servers. Tool distribution figures come from an arXiv study (2603.23802) tracking 177,436 MCP tools over 16 months.

Where are all these MCP servers actually running?

The 10,000-server headline needs context. According to security research firm Clutch Security, 86% of MCP servers are running locally on developer machines. Only 5% are deployed to production environments handling real traffic. The remaining 9% live in staging or CI/CD pipelines.

This gap matters because registry counts include every published version of every server ever listed — demos, tutorials, experiments that still show up as "active" records even if nobody has touched them in months. The production fleet is considerably smaller. It also explains why security tends to get deprioritised during development: if 86% of your testers are running the server on a laptop with no external traffic, they may never encounter the failure modes that appear when real AI agents start hitting your endpoint from multiple IPs in parallel.

Does your MCP server actually know who's calling it?

The July 2026 MCP specification release candidate brought the most significant security hardening since the protocol launched: mandatory iss parameter validation per RFC 9207, OpenID Connect application_type declarations during dynamic client registration, explicit credential binding to specific authorization server issuers. This is meaningful work on the spec side. The question is whether deployed servers have implemented any of it.

The answer is largely no.

A 2026 security audit of public and enterprise MCP deployments found that only 8.5% of servers implement OAuth 2.1 — the authentication method the specification has mandated for remote servers since March 2025. The most common approach is static API keys or personal access tokens, relied on by 53% of servers. These credentials don't expire, can't be scoped to individual tools, and are frequently stored in ways that make them easy to leak — hardcoded in config files, checked into version control, echoed in server logs.

Twenty-five percent of servers have no authentication at all.

Only 18% of surveyed deployments implement any form of tool-level permission scoping. Without it, a valid credential is effectively a master key: whoever holds it can call every tool the server exposes. For read-only tools that return public data, that exposure is limited. For action tools that modify state, send messages, edit files, or trigger transactions, it's a much bigger problem. And action tools now make up 65% of the MCP ecosystem — up from 27% in early 2025, per the arXiv study of 177,436 tools tracked over 16 months. The majority of what MCP servers actually do can cause real-world consequences when called incorrectly or maliciously.

What are the actual vulnerabilities, and how bad is it?

More than 30 MCP CVEs were disclosed in just the first two months of 2026. CVE-2025-6514 — a command injection vulnerability rated CVSS 9.6 — affected a package with over 437,000 downloads before it was caught. That's not a niche library; that's mainstream infrastructure being exploited.

The underlying vulnerability patterns are consistent across audits. Equixly's offensive-security assessment found command injection vulnerabilities in 43% of tested servers. The mechanism is almost always the same: an MCP tool accepts input from the AI agent and passes it, without sanitisation, directly to a shell command or system call. In the MCP context this is especially dangerous because the "user" is an AI agent that can itself be manipulated through prompt injection. An adversarial document that poisons the agent's context can cascade into arbitrary code execution on your server if the tool doesn't validate what the agent is sending.

SSRF (server-side request forgery) appeared in 36.7% of the 7,000+ servers BlueRock Security tested. The pattern is predictable: a URL-fetching tool that doesn't validate whether the target URL is internal to the server's own network. One cleverly crafted prompt instruction to the agent, and the tool happily fetches internal.admin.example.com/users.

Seventy-nine percent of servers audited handled credentials in plaintext at some point in their execution flow. Often in error messages or debug logs rather than config files, but present regardless — and that information shouldn't be there.

What does this actually mean if you're running a public MCP endpoint?

The protocol gives AI agents a richer, more structured way to interact with your site than crawling HTML. Instead of having an AI crawler infer what your product does from a rendered page, a properly built MCP server can expose exactly the tools and data you want the agent to see, in a format it can act on directly.

But it means you're exposing an executable interface to the web, not just markup. The security bar is higher than it is for a static page.

Before any MCP endpoint goes public, a short checklist is worth running through. Does every tool validate its inputs before passing them to a shell, database query, or outbound fetch? Are credentials scoped to specific tools rather than server-wide? Can you audit which tools were called, by which client, at what time? Are action tools — the ones that write, send, or modify — protected by stricter auth requirements than read-only ones?

The July 2026 spec gives you better primitives than before: stateless sessions that work with standard load balancers, mandatory Mcp-Method and Mcp-Name headers that let gateways enforce per-operation rate limiting without inspecting request bodies, full JSON Schema 2020-12 validation for tool parameters. The infrastructure for building secure production MCP exists. The gap is that 91.5% of production servers haven't implemented the basics the spec already required before those improvements arrived.

MCP's growth is genuine and the direction is clear. But growth numbers and security posture are separate things, and right now the second one hasn't caught up with the first.