12,000 AI ‘Tool Servers’ Are Plugged Into Chatbots Now—Here’s the Security Assumption Almost Every Company Is Getting Wrong
MCP turns chatbots into operators that can touch files, secrets, and production systems. The mistake: treating tool servers like harmless plugins instead of a privileged part of your perimeter.
By TheMurrow Editorial
May 11, 2026
Key Points
- 1Recognize MCP servers as a fast-growing plugin layer: directory-visible counts (12,700+ vs 6,152 vs 775+) don’t equal trust.
- 2Treat tools as perimeter: MCP servers can reach files, tokens, and production SaaS—privileged integrations are not “just integrations.”
- 3Act immediately: inventory approved servers, constrain permissions, and centralize distribution—because “local stdio” can still become command execution.
The new number you keep hearing—12,000 AI tool servers—isn’t a milestone. It’s a warning label.
In the past year, the AI industry has sprinted from chatbots that answer questions to “agentic” systems that do things: open tickets, edit code, query databases, deploy builds, move money. To make that possible, AI clients need a standardized way to reach outside the model and into the real world.
That’s what Model Context Protocol (MCP) servers provide: a growing layer of small services that expose tools—APIs, SaaS actions, local OS functions, database queries—to AI applications over a common interface. And depending on which directory you consult, there are already thousands of them.
The problem is not only scale. It’s that the plugin era has returned—except the plugins can touch your filesystem, your secrets, and your production systems. Security teams have seen this movie before. The difference now is that the “user” clicking “install” might be an AI workflow embedded in your development process.
“When agents get tools, tool security becomes AI security.”
— — TheMurrow Editorial
What “12,000 AI tool servers” actually means (and why the number keeps changing)
The phrase “12,000 AI tool servers” is usually shorthand for directory-visible MCP servers, not a definitive census of what exists in the wild.
MCP servers are distributed through multiple channels—GitHub repositories, community lists, vendor docs, internal enterprise catalogs—and each directory uses different rules for what counts. That’s why public totals vary so dramatically.
MCP servers are distributed through multiple channels—GitHub repositories, community lists, vendor docs, internal enterprise catalogs—and each directory uses different rules for what counts. That’s why public totals vary so dramatically.
A directory number, not a canonical inventory
One of the closest matches to the headline figure comes from PulseMCP, which shows 12,700+ servers—for example, “Showing 1–42 of 12,724 servers,” with daily updates. That number signals volume, but it also reflects the directory’s inclusion posture: broad, fast-moving, and inevitably uneven.
Other directories emphasize verification, and their counts shrink accordingly:
- MCP Find lists 6,152 verified servers across categories, explicitly filtering for “verified.”
- mcplist.ai advertises 775+ verified servers, with even narrower criteria.
- GitHub hosts an official/community MCP servers repository, but it’s a distribution channel more than a universal count.
Those gaps aren’t just clerical. They’re a preview of the security challenge: even informed teams may struggle to answer the basic question, Which tool servers are we actually trusting?
Other directories emphasize verification, and their counts shrink accordingly:
- MCP Find lists 6,152 verified servers across categories, explicitly filtering for “verified.”
- mcplist.ai advertises 775+ verified servers, with even narrower criteria.
- GitHub hosts an official/community MCP servers repository, but it’s a distribution channel more than a universal count.
Those gaps aren’t just clerical. They’re a preview of the security challenge: even informed teams may struggle to answer the basic question, Which tool servers are we actually trusting?
“A server count is easy to quote. Trust is harder to measure.”
— — TheMurrow Editorial
The missing majority: private, internal, and unlisted servers
Public directories capture what developers choose to publish, not what enterprises deploy. Many MCP servers are likely private—built for internal systems, shipped as managed components, or tucked behind corporate controls.
So treat “12,000” as a visibility metric: how much surface area is being advertised to the ecosystem, not how many instances exist in production. That distinction matters, because supply-chain risk often starts where discovery is easiest.
So treat “12,000” as a visibility metric: how much surface area is being advertised to the ecosystem, not how many instances exist in production. That distinction matters, because supply-chain risk often starts where discovery is easiest.
12,700+
PulseMCP’s directory-visible MCP servers (example listing: “Showing 1–42 of 12,724 servers”), updated daily—volume, not assurance.
6,152
MCP Find’s “verified” servers—smaller than broad directories, but still not a canonical inventory or a security audit.
775+
mcplist.ai’s “verified” servers—an even narrower gate that signals how quickly counts change with stricter criteria.
MCP in plain terms: the new plugin layer for AI clients
MCP’s core pitch is straightforward: an open standard that lets AI applications connect to external tools and data sources. According to MCP’s own documentation, the architecture centers on a client ↔ server relationship, using a standardized messaging style (often described as JSON-RPC-like) to expose tools, resources, and prompts.
In practice, MCP servers are small bridges between an AI client and a capability: “read this database,” “open this file,” “post to this SaaS,” “run this action.” The promise is interoperability—swapping tools without rebuilding your entire AI application.
In practice, MCP servers are small bridges between an AI client and a capability: “read this database,” “open this file,” “post to this SaaS,” “run this action.” The promise is interoperability—swapping tools without rebuilding your entire AI application.
Why MCP matters now: the agentic turn
The current AI shift isn’t only better models. It’s the workflow change: AI assistants moving from “advisor” to “operator.” Developers increasingly expect AI tools to:
- inspect and modify local code
- fetch and write data in SaaS systems
- execute actions in CI/CD pipelines
- retrieve information from internal knowledge bases
MCP is one way the industry is standardizing those connections. And standardization tends to accelerate adoption. A common interface lowers friction, and low friction produces scale.
- inspect and modify local code
- fetch and write data in SaaS systems
- execute actions in CI/CD pipelines
- retrieve information from internal knowledge bases
MCP is one way the industry is standardizing those connections. And standardization tends to accelerate adoption. A common interface lowers friction, and low friction produces scale.
Claude normalizes the pattern—and warns you about it
Anthropic’s support documentation for Claude Desktop and Claude Code describes how users and organizations add MCP servers so Claude can call external tools. Crucially, Anthropic also issues a clear warning: third-party MCP servers are used “at your own risk” and are not verified for security or correctness.
That warning is responsible. It’s also a sign that we’ve entered a familiar phase of platform history: the moment when an extension ecosystem outgrows the ability of any single company to vouch for it.
That warning is responsible. It’s also a sign that we’ve entered a familiar phase of platform history: the moment when an extension ecosystem outgrows the ability of any single company to vouch for it.
Key Insight
A directory listing is not a registry, and “verified” is not “secure.” MCP makes interoperability cheap—which makes trust mistakes expensive.
Why security teams are nervous: “tooling becomes the perimeter”
The security anxiety around MCP isn’t abstract. MCP servers can run with serious privileges: local filesystem access, developer credentials, API tokens, and write permissions inside production-adjacent SaaS tools.
Once an AI client can call a tool server, the tool server becomes part of the security boundary, whether a team treats it that way or not.
Once an AI client can call a tool server, the tool server becomes part of the security boundary, whether a team treats it that way or not.
The three common assumptions that keep showing up
Recent analysis has converged on a set of recurring misunderstandings—assumptions that make sense culturally (“it’s just an integration”) but fail technically.
Assumption #1: “These are just integrations.”
Reporting and commentary, including analysis from The Coding Zebra, argue the opposite: MCP servers may sit in privileged positions, and tool access often equals capability to cause real change.
Assumption #2: “If it’s in a directory or on GitHub, it’s probably safe.”
Directory counts in the thousands—12,700+ on PulseMCP—signal abundance, not assurance. Verification varies widely. Dupes and forks exist. Stale entries linger. Attackers thrive in precisely this kind of noise.
Assumption #3: “Local transport means local safety.”
Local MCP setups often rely on stdio transport, which can be operationally convenient. OX Security’s research argues that local transport can also create a dangerous path if untrusted configuration or orchestration turns “connectivity” into “code execution.”
Assumption #1: “These are just integrations.”
Reporting and commentary, including analysis from The Coding Zebra, argue the opposite: MCP servers may sit in privileged positions, and tool access often equals capability to cause real change.
Assumption #2: “If it’s in a directory or on GitHub, it’s probably safe.”
Directory counts in the thousands—12,700+ on PulseMCP—signal abundance, not assurance. Verification varies widely. Dupes and forks exist. Stale entries linger. Attackers thrive in precisely this kind of noise.
Assumption #3: “Local transport means local safety.”
Local MCP setups often rely on stdio transport, which can be operationally convenient. OX Security’s research argues that local transport can also create a dangerous path if untrusted configuration or orchestration turns “connectivity” into “code execution.”
“The most privileged integrations are often treated as the least threatening.”
— — TheMurrow Editorial
Why this feels like a supply chain problem, not a bug problem
Traditional app security focuses on vulnerabilities in code you ship. MCP pushes risk outward—toward:
- the server implementation
- the SDK defaults
- the configuration and orchestration layer
- the discovery and distribution ecosystem
That’s supply chain territory: trust relationships, provenance, updates, and the long tail of third-party components.
- the server implementation
- the SDK defaults
- the configuration and orchestration layer
- the discovery and distribution ecosystem
That’s supply chain territory: trust relationships, provenance, updates, and the long tail of third-party components.
The OX Security disclosures (April 2026): “the mother of all AI supply chains”
On April 15, 2026, OX Security published research framing MCP’s growth as a systemic supply-chain exposure, emphasizing risks around STDIO transport and scenarios where configuration flows can be manipulated into command execution.
Their technical narrative is pointed: an attacker doesn’t always need to “hack the model.” They can target the tool layer—especially when “test connection” or setup mechanisms can be influenced.
Their technical narrative is pointed: an attacker doesn’t always need to “hack the model.” They can target the tool layer—especially when “test connection” or setup mechanisms can be influenced.
What OX described: from configuration to command execution
OX Security’s write-up describes scenarios where an attacker can intercept or alter requests and swap in a STDIO payload to achieve arbitrary command execution, including on production systems under certain conditions.
The core lesson is not that every MCP server is dangerous. It’s that the ecosystem’s rapid growth makes “sharp edges” in defaults, orchestration, and trust boundaries far more consequential.
The core lesson is not that every MCP server is dangerous. It’s that the ecosystem’s rapid growth makes “sharp edges” in defaults, orchestration, and trust boundaries far more consequential.
The reported scale: downloads and deployed instances
Coverage summarizing the research, including reporting from Tom’s Hardware, described a potential blast radius spanning:
- ~150 million downloads (attributed to the research and its interpretation)
- up to ~200,000 deployed server instances (again attributed to OX’s findings and follow-on reporting)
Those figures matter because they capture the supply-chain dynamic: a small design assumption, multiplied across distribution channels, becomes a systemic risk.
- ~150 million downloads (attributed to the research and its interpretation)
- up to ~200,000 deployed server instances (again attributed to OX’s findings and follow-on reporting)
Those figures matter because they capture the supply-chain dynamic: a small design assumption, multiplied across distribution channels, becomes a systemic risk.
~150 million
Reported download-scale blast radius in follow-on coverage of OX Security’s April 15, 2026 MCP research (as attributed in that reporting).
~200,000
Reported upper bound on deployed MCP server instances in follow-on coverage of OX Security’s research (as attributed in that reporting).
The controversy: “expected behavior” versus vulnerability framing
Reporting also highlighted a dispute over characterization—OX framing the behavior as a serious flaw, while Anthropic allegedly described the behavior as “expected.”
Both perspectives can coexist. Platform designers often see protocol flexibility as a feature; security researchers often see the same flexibility as an exploit path when real-world usage includes untrusted inputs, rushed integrations, and optimistic defaults. The practical question for enterprises is simpler: Do we treat the MCP tool layer as part of our perimeter? If the answer is yes, then “expected” still needs to be “controlled.”
Both perspectives can coexist. Platform designers often see protocol flexibility as a feature; security researchers often see the same flexibility as an exploit path when real-world usage includes untrusted inputs, rushed integrations, and optimistic defaults. The practical question for enterprises is simpler: Do we treat the MCP tool layer as part of our perimeter? If the answer is yes, then “expected” still needs to be “controlled.”
Bottom line
The debate over “expected behavior” doesn’t change the operational requirement: if tools can touch secrets, code, or production SaaS, they must be governed like perimeter components.
Directories, verification, and the trust gap: why discovery is part of the risk
The MCP ecosystem is not one marketplace. It’s an archipelago of lists, repos, examples, and copy-pasted configs. That fragmentation is fertile ground for mistakes.
Consider the verification spread:
- PulseMCP: 12,700+ listed servers (broad inclusion)
- MCP Find: 6,152 verified servers (curated verification posture)
- mcplist.ai: 775+ verified servers (narrower gate)
A directory’s number is not a quality signal. It’s a policy signal.
Consider the verification spread:
- PulseMCP: 12,700+ listed servers (broad inclusion)
- MCP Find: 6,152 verified servers (curated verification posture)
- mcplist.ai: 775+ verified servers (narrower gate)
A directory’s number is not a quality signal. It’s a policy signal.
Verification is not binary—and “works” is not the same as “safe”
Even “verified” rarely means “secure.” It often means “it runs,” “it matches a description,” or “it passed some basic checks.” That’s helpful, but it’s not the same as a security audit, reproducible builds, or a documented threat model.
Anthropic’s own documentation underscores this reality by warning users that third-party MCP servers are unverified and used at their own risk. That statement doesn’t condemn the ecosystem. It clarifies the responsibility boundary.
Anthropic’s own documentation underscores this reality by warning users that third-party MCP servers are unverified and used at their own risk. That statement doesn’t condemn the ecosystem. It clarifies the responsibility boundary.
Real-world example: the developer who just wants their assistant to ship
The typical adoption story is mundane: a developer installs a server to let their AI assistant query a database, open a local repo, or call a SaaS API. They want convenience, not complexity.
MCP delivers convenience quickly. It also encourages a familiar anti-pattern: granting broad permissions early (“just to get it working”) and narrowing later (often never). If a tool server can read files, run commands, or access tokens, the cost of “later” can be enormous.
MCP delivers convenience quickly. It also encourages a familiar anti-pattern: granting broad permissions early (“just to get it working”) and narrowing later (often never). If a tool server can read files, run commands, or access tokens, the cost of “later” can be enormous.
Practical implications: what teams should do Monday morning
Security guidance that boils down to “be careful” is useless. The MCP tool layer is already embedded in real workflows. The workable approach is to treat MCP servers like any other privileged component in your stack—because that’s what they are.
For security leaders: make the tool layer auditable
Start with governance and inventory. If a team can’t list its MCP servers, it can’t secure them.
Practical steps:
- Inventory and classify MCP servers: public vs internal, local vs remote, read-only vs write-capable.
- Constrain permissions: minimize filesystem access, scope API tokens, and avoid broad write privileges by default.
- Centralize distribution: prefer controlled, organization-approved catalogs over ad hoc installs.
Anthropic’s enterprise documentation points toward organizational controls (such as enabling/disabling public extensions and distributing configurations via endpoint management). The security value is obvious: reduce shadow IT in the tool layer.
Practical steps:
- Inventory and classify MCP servers: public vs internal, local vs remote, read-only vs write-capable.
- Constrain permissions: minimize filesystem access, scope API tokens, and avoid broad write privileges by default.
- Centralize distribution: prefer controlled, organization-approved catalogs over ad hoc installs.
Anthropic’s enterprise documentation points toward organizational controls (such as enabling/disabling public extensions and distributing configurations via endpoint management). The security value is obvious: reduce shadow IT in the tool layer.
Monday-morning governance checklist
- ✓Inventory and classify MCP servers (public/internal, local/remote, read/write)
- ✓Constrain permissions (filesystem scope, token scope, least-privilege by default)
- ✓Centralize distribution (approved catalogs over ad hoc installs)
For developers: treat MCP servers like dependencies with teeth
Developers already understand dependency hygiene. Apply the same discipline to MCP:
- Prefer servers with clear provenance and maintenance signals.
- Avoid running untrusted servers locally with high privileges.
- Keep configs reviewed; don’t accept “paste this JSON and run it” workflows without scrutiny.
The OX Security narrative around STDIO and command execution is a reminder: local does not automatically mean safe. Local often means closer to secrets.
- Prefer servers with clear provenance and maintenance signals.
- Avoid running untrusted servers locally with high privileges.
- Keep configs reviewed; don’t accept “paste this JSON and run it” workflows without scrutiny.
The OX Security narrative around STDIO and command execution is a reminder: local does not automatically mean safe. Local often means closer to secrets.
For vendors and directory operators: verification needs to mean something
Directory growth is inevitable; trust must scale with it. That doesn’t require a single gatekeeper, but it does require better signals—clearer verification criteria, provenance metadata, and visibility into maintenance and ownership.
A mature ecosystem usually develops layers: quick discovery lists, curated lists, and enterprise-grade registries. MCP is early enough that these norms are still being formed. Teams that push for higher standards now will reduce the long-term security tax.
A mature ecosystem usually develops layers: quick discovery lists, curated lists, and enterprise-grade registries. MCP is early enough that these norms are still being formed. Teams that push for higher standards now will reduce the long-term security tax.
Editor’s Note
Treat MCP servers as privileged components, not convenience add-ons: inventory, permission, provenance, monitoring, and centralized distribution are the baseline.
Where this goes next: the extension era, rewritten for AI
Extension ecosystems tend to follow a predictable path. They begin with experimentation, then explode into abundance, then become a security battleground, and finally mature into managed platforms with strong controls.
MCP is somewhere between abundance and battleground.
The numbers alone show why. One directory listing 12,700+ servers signals a flourishing developer culture. Another listing 6,152 verified servers signals the first serious attempt to impose order. A third listing 775+ verified servers signals what enterprises eventually demand: narrow trust, strong guarantees.
Meanwhile, the April 2026 OX Security disclosures—and the controversy over whether certain behaviors are “expected”—highlight the industry’s growing pains. Protocol designers value flexibility. Attackers value flexibility more.
The sober takeaway is not that MCP is “unsafe.” It’s that the tool layer is now the perimeter, and perimeters don’t thrive on informal trust.
The next year will likely reward teams that treat MCP servers as first-class citizens in their security model: inventoried, permissioned, monitored, and governed. The rest will learn the hard way that giving an AI system tools is not an accessory feature. It’s an architectural choice.
MCP is somewhere between abundance and battleground.
The numbers alone show why. One directory listing 12,700+ servers signals a flourishing developer culture. Another listing 6,152 verified servers signals the first serious attempt to impose order. A third listing 775+ verified servers signals what enterprises eventually demand: narrow trust, strong guarantees.
Meanwhile, the April 2026 OX Security disclosures—and the controversy over whether certain behaviors are “expected”—highlight the industry’s growing pains. Protocol designers value flexibility. Attackers value flexibility more.
The sober takeaway is not that MCP is “unsafe.” It’s that the tool layer is now the perimeter, and perimeters don’t thrive on informal trust.
The next year will likely reward teams that treat MCP servers as first-class citizens in their security model: inventoried, permissioned, monitored, and governed. The rest will learn the hard way that giving an AI system tools is not an accessory feature. It’s an architectural choice.
T
About the Author
TheMurrow Editorial is a writer for TheMurrow covering technology.
Frequently Asked Questions
What are “AI tool servers” in the MCP context?
In most current usage, “AI tool servers” refers to MCP servers: small services that expose tools (API calls, database queries, local OS actions, SaaS operations) to an AI client through a standardized interface. Instead of the model doing everything internally, the client asks the MCP server to perform specific actions and returns results to the model.
Why do some sites say there are 12,000+ servers while others list far fewer?
Counts differ because directories use different inclusion rules. PulseMCP lists 12,700+ servers with broad coverage, while MCP Find lists 6,152 verified servers, and mcplist.ai lists 775+ verified. Verification criteria, duplicates, forks, and stale entries all change the totals. No single canonical registry exists.
Are MCP servers inherently insecure?
No. MCP is a protocol, and many MCP servers may be well-built. The risk comes from privilege and trust: tool servers can access files, secrets, or production SaaS systems, and the ecosystem is growing quickly. As Anthropic warns in its documentation, third-party MCP servers are generally unverified and used at the user’s risk.
What did OX Security report in April 2026?
OX Security published research dated April 15, 2026 describing systemic risks in the MCP ecosystem, emphasizing STDIO transport and scenarios where configuration or orchestration flows could be manipulated into arbitrary command execution. Follow-on reporting summarized the potential scale as ~150M downloads and up to ~200,000 deployed instances, as attributed to the research.
If an MCP server runs locally, isn’t it safer than a remote server?
Local reduces some network exposure, but it can increase others. A local server may sit closer to sensitive assets: source code, SSH keys, tokens, and developer credentials. OX Security’s reporting argues that local STDIO-based flows can become dangerous if untrusted inputs or configuration can influence what is executed on the machine.
What should an enterprise do before allowing MCP servers broadly?
Start with governance: maintain an inventory of approved servers, restrict permissions, and centralize distribution. Anthropic’s documentation describes organizational controls such as enabling/disabling public extensions and distributing configurations via endpoint management. The goal is to prevent ad hoc installations that quietly introduce high-privilege components into developer and production workflows.
