The Rise of MCPs: 225 MCP servers per organization

At Natoma, we help enterprises get control of the growing sprawl of Model Context Protocol (MCP) servers. We begin by discovering what’s already running inside the organization—often uncovering servers employees are already using—and the early findings are eye-opening.

On average, we’re seeing 225 MCP servers per organization already in use.

That’s remarkable, considering we’re still in the very early days of MCP adoption. Right now, MCPs are mostly used through IDEs, which means usage is limited to technical teams. But this is only the beginning. As more clients and workflows plug into MCPs, their presence across organizations will multiply rapidly.

Why this matters

Each MCP server represents a new integration point, a new surface area for productivity—and for risk. While these servers are enabling developers to move faster, they’re often spun up and managed in an ad hoc way. That raises key questions:

• How many are running?

• Are these servers secure?

• Are they following organizations' authentication guidelines?

• Could your teams move faster if these servers were hosted and managed on a secure gateway?

How enterprises are using MCP servers today

MCP servers act as connectors: they expose organizational systems, datasets, and APIs to LLMs in a discoverable way. Today, we’re seeing them pop up in:

• Developer IDEs — engineers are spinning up MCP servers to let their copilots pull code context, query APIs, or debug environments.

• Prototyping Environments — quick local servers for one-off experiments or proof-of-concepts.

• Team-Specific Workflows — small groups wiring MCPs into test harnesses, ITSM, Design systems, QA scripts, or CI/CD pipelines.

Security & scale problem

225 MCPs might sound like a lot—but that’s just the baseline. As adoption expands beyond IDEs, expect that number to grow 5–10x. That scale raises critical issues:

Duplicate effort

Across different teams, engineers are building and running their own MCP servers to solve similar problems. For example:

• One group spins up an MCP to expose a CI/CD pipeline to an IDE.

• Another team builds almost the same MCP, but pointed at a slightly different environment.

• A third group writes a connector for an internal API, unaware that another team already did the same thing.

The result? Dozens of duplicate MCPs, each with their own quirks, configs, and maintenance costs. What should be a productivity accelerator becomes a patchwork of siloed, redundant efforts.

This wastes valuable engineering cycles — and more dangerously, it fragments security and governance.

Patterns of Misconfiguration & Attack Surface Expansion

From both real-world observations and internal scans, we see recurring issues:

• Weak or missing authentication — many MCPs trust any caller.

• Malicious supply chain — e.g. the postmark-mcp NPM backdoor silently exfiltrated emails via BCC.

• Excessive permissions — broad API, email, or DB scopes instead of least privilege.

• Insecure defaults / logging — secrets and payloads written in plaintext.

• Unpatched dependencies — servers deployed once and forgotten.

• Lateral pivoting — compromised MCPs become jump-off points into internal systems.

Unintentional Permissioning Issue

Here’s a real incident that underscores the risks:

We shut down our Asana MCP server after Claude used it to create a manager’s tasks and unintentionally exposed task data to everyone.

The server wasn’t malicious — it just wasn’t properly scoped or locked down. But the outcome was serious: sensitive project information was suddenly visible far more broadly than intended.

This is exactly the kind of risk that emerges when MCPs are deployed ad hoc, with no consistent authentication, authorization, or policy enforcement.

Case for a managed MCP gateway

Instead of hundreds of scattered, unmanaged servers, organizations can centralize MCPs on a secure, hosted gateway solving both security and velocity problems:

• Visibility: a single inventory of every MCP.

• Security: standardized auth, TLS, logging, and policy enforcement.

• Efficiency: eliminate duplicates — build once, reuse everywhere.

• Velocity: free engineers to create AI-driven workflows instead of reinventing server infrastructure.

Your engineers should be crafting AI experiences, not spending time patching, hosting, and securing dozens of redundant MCP servers. The MCP footprint is only going to grow. The time to get ahead of it is now.

👉 Go to Natoma.ai and see how many MCP servers your organization is already running for free!