Is Your MCP Server Safe to Ship? What Scanning 7,000 Deployments Actually Found

22,311 — that's how many MCP servers PulseMCP was tracking as of July 16, 2026. Compare that to the roughly 50 servers that existed when the protocol launched in November 2024. In under 20 months, the Model Context Protocol went from a niche specification to a functioning ecosystem with tens of thousands of public deployments and 97 million monthly SDK downloads.

Here's what didn't scale at the same pace: the security practices. BlueRock Security scanned around 7,000 public MCP servers and published their findings in mid-2026. The headline figure is hard to look past — 41% of the servers they tested required no authentication at all. Not weak auth. None whatsoever. Any agent that knows the endpoint can call the tools.

So how worried should you be? That depends entirely on what those tools are actually doing.

Where does this data come from?

Server counts come from PulseMCP's public registry and an independent pull of the official MCP Registry API on May 24, 2026, which returned 9,652 latest server records and 28,959 versioned records. GitHub showed 15,926 repositories tagged as mcp-server on the same date — those two numbers don't perfectly overlap since not every GitHub server is registered and vice versa, but they bracket the real count.

The security data comes from BlueRock Security's mid-2026 audit of approximately 7,000 public MCP servers, covering authentication method, SSRF exposure, and tool scope. The 97 million monthly download figure comes from the January 2026 ecosystem update on the protocol's official channels.

How fast is this actually growing?

The growth trajectory is essentially parabolic. Fifty servers at launch in November 2024. Ten thousand active public servers by early 2026. Over twenty-two thousand by mid-July. For reference, that rate puts MCP among the fastest API standard rollouts on record.

What this means practically: AI assistants that speak MCP can now connect to a meaningful fraction of the web's tools and datasets without any per-integration engineering work. The "nobody's using this yet" window has closed. Sites with an MCP server are already participating in a network that AI agents are actively querying. Sites without one are increasingly invisible to those agents when tool-calling is how the interaction works.

What kind of access are these 22,000 servers actually exposing?

The typical public MCP server exposes a median of five tools. Category distribution has stabilised around a few dominant patterns: database reads, version control queries, document retrieval, cloud infrastructure access, and communication integrations like email, Slack, and calendar tools.

"Read-only" sounds safe until you look at what's being read: customer records, internal documentation, financial summaries, user account data. Read access to a CRM is technically read-only. It's also a significant exposure if the auth layer protecting it is a shared static key or nothing at all.

The fastest-growing category in H1 2026 was communication — tools that send messages, post updates, or create calendar entries. These carry a different risk profile than data lookups: a compromised MCP endpoint that can post to your company Slack or email a customer isn't a passive data exposure, it's an active incident with measurable consequences.

Is 8.5% OAuth adoption actually a problem?

The protocol specification is explicit: OAuth 2.1 is the required authentication standard for remote MCP server deployments. Eight and a half percent of public servers implement it.

Of the 59% of servers that do have some authentication, 53% rely on static API keys. Static keys can be rotated, but they can't be scoped to specific users or delegated without being shared. They generate no inherent audit trail. When one leaks — and in practice they do leak, through logs, repositories, and error messages — you find out after the fact.

The 36.7% SSRF vulnerability rate compounds the auth picture considerably. Server-side request forgery lets a crafted input cause an MCP server to make outbound requests it wasn't intended to make, potentially to internal services that trust the server by virtue of network position. Combine an unauthenticated server with an SSRF flaw and you have a path to internal network reconnaissance through a publicly exposed AI tool endpoint. Several published case studies from H1 2026 describe this exact attack chain in production environments.

The structural explanation for why auth is lagging: MCP originally ran over stdio transport, meaning an AI assistant and its tools both ran locally on the same machine. In that model, OS-level user permissions are the security layer — no protocol-level auth required. When those same servers get deployed remotely to production infrastructure, the local auth assumptions don't transfer. The code often does.

Does this affect you if you don't run an MCP server?

Indirectly, yes. MCP clients often connect to multiple servers simultaneously, and tool poisoning attacks against this multi-server configuration have been demonstrated against several popular clients in 2026.

The pattern works like this: a malicious MCP server in a bundle returns tool definitions that include instructions intended to influence how the client behaves with every other server in that session. Your legitimate MCP tools end up being called in a context shaped by a third-party server you didn't choose and can't control. This is a materially different threat model from a REST API, where your own authentication model defines your entire security surface.

So what should you actually do about this?

If you're shipping a remote MCP server right now, three things matter more than anything else.

Implement OAuth 2.1. Not because it's a nice-to-have — because the specification requires it for remote deployments and the AI client ecosystem is beginning to enforce this at connection time. Servers running static keys will increasingly be flagged by security-conscious clients as trust signals mature.

Publish a .well-known/mcp.json discovery file. Client-side autodiscovery is maturing fast. AI assistants that support MCP are beginning to check this endpoint to detect available tools without manual configuration. A published discovery file means your server is findable in that process; without it, you're invisible to automated discovery flows that are becoming how agents navigate the tool landscape.

Validate every URL your server can be asked to fetch. SSRF is the most common exploitable vulnerability class in the current MCP ecosystem by a significant margin. If your server makes outbound HTTP requests based on agent-supplied input — fetching documents, checking URLs, querying external services — validate against an explicit allowlist before the request is made. SSRF mitigations are well understood; the problem in the current ecosystem is that they're not being applied.

The 22,311 number says the MCP ecosystem is real and growing fast. The 41% no-auth figure says most of it was built quickly, not carefully. That gap is going to narrow — either through the ecosystem converging on better defaults, or through the kind of incident-driven adoption curve that eventually hardened every previous API generation. Building to the spec now is considerably less painful than retrofitting after something goes wrong.