The MCPTox benchmark tested 45 live MCP servers against poisoned tool descriptions across a range of current LLMs. Attack success rates ran above 60% for many popular agents. The most capable models often performed worse than smaller ones - their superior instruction-following made them more obedient to malicious metadata, not less. The highest attack success rate in the study was 72%, and Claude 3.7 Sonnet, the most resistant model tested, still failed to refuse poisoned tool calls less than 3% of the time.
That is the actual state of MCP server security right now, while the ecosystem celebrates its server count.
The MCP server ecosystem grew from roughly 100 servers at launch in November 2024 to over 19,800 on Glama's registry by March 2026. That growth story has been told as a sign of protocol maturity, a sign that MCP has "won" the AI integration standards race. It hasn't. It's a sign that anyone can publish a server, and most of them have not been audited, stress-tested, or secured. The server count is a vanity metric. The ecosystem's real problem is trust - and the 2026 roadmap, for all its good work on stateless transport and governance structure, does not solve it.
What the security scans actually found
Offensive security assessments found command injection vulnerabilities in 43% of tested MCP servers, SSRF vulnerabilities in 36.7% of over 7,000 servers scanned, and critical vulnerabilities in 33% of 1,000 servers scanned by Enkrypt AI. A separate scan from AgentSeal reported that 66% of 1,808 servers it examined had some security finding.
The MCP authorization specification defines an OAuth 2.1 framework but explicitly marks authorization as optional, leaving MCP servers exposed without authentication - a July 2025 internet scan identified at least 1,862 publicly accessible instances responding to unauthenticated requests.
The attack class that matters most for agent pipelines is tool poisoning. Tool-poisoning attacks target agentic AI systems by hiding malicious instructions in tool descriptions, metadata, or configurations, causing the AI to misuse tools for data exfiltration, arbitrary command execution, or behavior hijacking - and they differ from general prompt injection by exploiting trusted tool interfaces, including "rug pulls" where a benign tool turns malicious after approval. The insidious thing about a rug pull: your agent passed your tests, connected to a server that looked legitimate, and something changed server-side without any notification mechanism in the protocol to catch it.
First production incidents have already made headlines - Asana's cross-tenant data leak, Smithery's path traversal exposing 3,243 apps, and tool poisoning attacks affecting open-source servers. These aren't edge-case research demonstrations. They're the first wave of real incidents in a protocol that is now powering enterprise workflows.
The exposure is not theoretical. The registry doesn't know which of its 19,000 servers are safe. Neither does your agent.
The steelman for moving fast anyway
Here is the honest counterargument: the alternative to a fast-growing, imperfect ecosystem is a slow-growing, locked-down one. If the MCP registry required security audits before listing, it would have 200 servers, not 20,000, and developers building agents would be writing bespoke integrations again - which have their own security problems and cost a lot more engineering time to maintain.
Rather than writing custom integrations for each system, teams can expose services via MCP servers and let models interact with them using the same protocol. That is a genuine engineering win. Before MCP, a startup building an AI product that needed to connect to five enterprise systems faced a choice: build five custom integrations and maintain them as those systems updated, or limit the product's scope to avoid the integration burden - and both paths had real costs. The protocol earned its adoption by solving a real problem.
The steelman also applies to the protocol's governance trajectory. MCP has grown into a multi-company open standard under the Linux Foundation.
In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI - signalling that MCP was no longer Anthropic's protocol but shared infrastructure, in the same category as HTTP or TCP/IP. Neutral governance means no single vendor can quietly tighten control. That matters.
But "the protocol is maturing" is not the same as "the servers are safe." The governance improvements in the 2026 roadmap are real: stateless transport, Server Cards for discovery without a live connection, enterprise auth paths. The 2026-07-28 release candidate - the largest revision since launch - delivers a stateless core that scales on ordinary HTTP infrastructure, an extensions framework, and authorization that aligns more closely with OAuth and OpenID Connect deployments. Good. None of that audits the servers that are already running.
What production deployments actually look like when they work
Pinterest's production MCP deployment, detailed in April 2026, runs domain-specific MCP servers for Presto, Spark, and Airflow behind a central registry, with human-in-the-loop approval for sensitive operations. The system recorded approximately 66,000 monthly invocations from 844 active users, saving an estimated 7,000 engineering hours per month - demonstrating that MCP can scale to real enterprise workloads when paired with proper governance, security review, and gateway infrastructure.
The phrase worth holding onto there is "behind a central registry." Pinterest did not point its agents at the public MCP ecosystem and trust that the servers were safe. It built its own curated registry, with approval gates. That is the pattern that works.
AI agents are now privileged identities. Treat them with the same governance, monitoring, and least-privilege controls you apply to admin accounts. That framing is more useful than any server count. An agent that can call a Slack API, write to a database, and send email on behalf of a user has the blast radius of an admin account. Connecting it to an untrusted MCP server is the equivalent of giving that admin account credentials to a third-party tool you found on GitHub last Tuesday.
The thing the server count hides
The broad conclusion is stable: MCP has crossed from niche developer protocol into mainstream agent infrastructure. That is true. The protocol won. But "the protocol won" and "the ecosystem is safe to use" are different claims, and the breathless server-count headlines conflate them.
What the 19,000-server number actually measures is developer interest in the protocol. It does not measure server quality, maintenance activity, security posture, or whether any of those servers will still behave the same way next month as they do today. How official and downstream registries handle trust, curation, and stale packages is still an open question - one the 2026 roadmap puts on the horizon but doesn't close.
Defense-in-depth is the only durable answer. Tool allowlisting, identity binding, runtime monitoring, and human-in-the-loop checkpoints - not any single control - are what limits blast radius.
The MCP ecosystem will eventually build the curation layer it needs. Registries will add security signals. Audit tooling will mature. The Linux Foundation governance will make that work easier to coordinate. None of that is here yet. In the meantime, the number to watch isn't server count. It's how many of those servers your organization has actually reviewed, allowlisted, and agreed to trust.
For teams wiring MCP servers into production agents - whether those agents live in a coding tool, a support workflow, or a Slack-based assistant - the right default is assume untrusted until verified. That's not a counsel of despair about MCP. It's just accurate.