MCP Server Discovery and Inventory in Enterprise Environments

Most enterprises can't tell you how many MCP servers are running inside their own walls, let alone what those servers touch. Before anyone can secure, audit, or govern the Model Context Protocol, someone has to find every server first, and right now almost nobody can. I asked three security leads at three different companies "how many MCP servers do you have running," and got three answers, all wrong, all confident.

Anthropic put out MCP in late 2024 to fix a real headache: every AI agent that needed to talk to a tool or database used to need its own custom integration, built by hand and maintained by hand forever after. MCP swapped that mess for one shared protocol. It caught on fast, too fast maybe; every major AI lab backs it now, and it sits under the Linux Foundation's new Agentic AI Foundation. That's a hell of a climb for a standard that isn't old enough to drink.

Speed like that costs something, and the bill is coming due. Adoption outran governance, and the production research on MCP already flags gaps in identity handling, logging, and error behavior that a protocol this widely deployed shouldn't still have. Three habits explain why these servers stay invisible even inside well-run IT shops. They usually log in with a person's own credentials, so an agent acting through that server shows up in the access logs looking exactly like the human, nothing separating the machine's clicks from the person's. They get spun up as side projects, by a developer, an ops team, someone in marketing, entirely outside any process anyone signed off on. Coding assistants will connect to servers running on a laptop or a stray cloud box without telling IT a single thing about it.

There's also the credential problem, which makes the blind spot worse. MCP servers routinely store API keys and tokens in plaintext, sitting in config files or environment variables, waiting for whoever finds them. A GitHub MCP server holding a personal access token in a config file can be read by any process or agent that reaches that file, no special skill required. Put it together and you get a live service with real access to real systems, sitting completely outside the asset inventory, the security monitoring, and every control built for the stuff IT actually knows about.

How MCP servers accumulate across an enterprise before anyone maps them

Nobody plans this. Marketing sets up a connector to its ad platform, operations builds an inventory tool, and customer service wires up a support integration, all without talking to each other or to IT. Each project looks small and sensible on its own. Stack them up, though, and you've got a mess nobody signed up for.

This is the N×M problem, and it gets worse the longer nobody's minding it. Once agents are talking to dozens of servers spread across departments, the web of connections stops being something anyone can track by memory or spreadsheet. Agents choke on it too. Give an agent forty available tools when it needs three, and it burns context and accuracy just figuring out which three matter.

Developer tooling speeds the whole thing up without anyone noticing. Claude Code connects to MCP servers without necessarily surfacing that activity to IT, and other coding assistants behave similarly, with no explicit decision required from the person at the keyboard. And it isn't just sprawl inside the walls: MCP servers are turning up on the open internet in cases where nobody meant for them to be reachable from outside at all.

The raw count of servers matters less than what each one can reach. A single ungoverned server might hold access to source code, cloud accounts, ticketing systems, internal docs, and production-adjacent business data, all through one login. The production research keeps circling back to the same hard question: which servers should get access to which systems? You can't answer that about a server you don't know exists.

Call it shadow AI if you want a label, since it shares plenty with shadow IT: tools running inside the perimeter that nobody approved or tracked. Shadow IT just sits there as a liability until someone trips over it, but shadow AI acts on its own, using whatever access it inherited, without a human clicking anything to greenlight it. Gartner expects a meaningful share of enterprises to hit security or compliance incidents tied to unauthorized AI use before the decade's out, and MCP sprawl is a direct line item in that math.

What complete MCP discovery actually requires

Discovery isn't a scan you run once and file away. It works in two modes, and each one answers a question the other can't touch.

Static discovery looks at code before anything runs: infrastructure-as-code files, container definitions, deployment scripts, repositories. It tells you what's being provisioned, what permissions are written down on paper, what connectivity got configured but maybe never shipped. Dynamic discovery goes the other way, scanning live environments across cloud, on-prem, and hybrid infrastructure continuously, catching what's actually running right now, including servers nobody declared anywhere.

You need both. Static discovery has no way to see a server someone spun up by hand outside the pipeline; dynamic discovery has no way to flag a dangerous config sitting in a repo that hasn't shipped yet. Skip either one and you're working from half a map.

There's a protocol-level fix trying to make this less painful. The /.well-known/mcp.json convention, proposed under SEP-1960, borrows the pattern OAuth 2.0 and OpenID Connect already use: a server publishes a structured discovery endpoint, and a client queries it without anyone hand-configuring the connection. SEP-1960 goes further and says servers in high-security environments should cryptographically sign those discovery responses. An unsigned response in a regulated setting is a trust gap sitting there, waiting to be pried open.

A discovery tool worth its license fee gives you something concrete: a record for every server showing where it lives, its transport type, its exposed tools and resources, how it authenticates, what downstream systems it can touch. It flags hardcoded secrets sitting in config files, catches external exposure, and updates continuously instead of handing you a snapshot from last Tuesday. Skip the tooling and you're doing all of it by hand, finding endpoints, wiring up auth, checking what talks to what. That works fine for five servers, but it falls apart at five hundred.

How current vendor tools approach MCP inventory

Vendors are attacking this from different angles, and where each one starts shapes what it catches first and what it misses entirely.

Token Security scans continuously for MCP servers and agentic processes, reading IDE and coding assistant logs to figure out which servers those tools are quietly talking to, close to real time. CyCognito works from the outside in: it hunts for MCP servers reachable from the public internet and folds them into external asset inventory, covering a blind spot most internally-focused scanners walk right past.

Qualys TotalAI builds a graph of the whole thing, every server as a node wired to its tools, its resources, its downstream systems. That structure surfaces things a flat list never will: which servers share access to the same internal system, which tool combinations create a trust path between environments that were supposed to stay separate, which prompt chains stack tools together in ways that widen the blast radius of one bad call.

Salt's MCP Finder positions itself as the system of record for the whole agentic action layer, tracking servers and tools across exposure, code, and live runtime behavior rather than a single point-in-time check. Azure API Center takes the registry route: a catalog of remote and local MCP servers registered through the Azure portal, exposing an endpoint that plugs into VS Code and GitHub Copilot, tying into Microsoft Foundry's tool catalogs for governance further downstream.

Different angles, same underlying belief: none of these tools enforce policy on a server they haven't found and catalogued first, so inventory comes before control, full stop. What none of them solve alone is the next step, because knowing a server exists isn't the same as governing it. The inventory only earns its keep once it connects to policy enforcement, identity checks, and audit logging, and that's a different product entirely.

Why inventory without a governance layer stays a spreadsheet problem

An inventory tells you what exists, where it runs, what it can touch, how it logs in. That's useful, but by itself, it's still only half the job.

It can't tell you who should be allowed to use that server, under what conditions, with what limits, and what record gets left behind afterward. Those are policy questions, and policy questions need a policy layer, not a list, no matter how well-organized the list is.

MCP didn't make this easy early on, either. The original spec shipped without a full authentication framework, and OAuth 2.1 support only landed in mid-2025. Support for it still varies a lot from one server to the next, so "the server supports OAuth" and "the server enforces OAuth correctly" turn out to be two very different claims, and the gap between them is where things go wrong.

This is where the gateway pattern earns its place. An MCP gateway sits in front of every server and becomes the one governed door everything passes through, enforcing authentication, routing, and policy no matter which client is knocking. In practice, the gateway intercepts the tools/list response and filters it based on who's asking and what they're cleared to touch. A tool the agent has no business using just doesn't show up in its context at all.

That filtering has a side benefit nobody designed for but everyone should appreciate. Agents reason better when the list of options in front of them is short and relevant, so cutting the action space down helps security and performance at the same time. Governance and accuracy move together here, not against each other, which is rarer than it should be in security tooling.

The DIY route racks up costs that don't show up until later, usually at the worst possible time. Every server needs its own auth wiring, governance turns into a scatter of scripts and one-off configs, and observability becomes the thing teams meant to add eventually and never did. Organizations end up thinking they have coverage when they're actually blind to most of the agent-to-tool traffic moving through their own systems. The official MCP roadmap has caught up to this: gateway and proxy patterns, enterprise-managed auth, and audit trails are core requirements now, not nice-to-haves. The spec is just formally agreeing with what production teams already learned the hard way, months late but at least it got there.

What enterprise teams should evaluate in an MCP gateway

A handful of things separate a gateway worth deploying from one that looks good in a demo and falls over in production.

Performance overhead matters more than people expect going in. Latency added per request compounds at real concurrency, and a vendor should show you numbers under realistic load, not a demo running three requests in a browser tab. Deployment flexibility is its own filter: self-hosted, managed, in-VPC, and air-gapped are genuinely different requirements, and a gateway locked to one mode rules itself out for regulated industries or anyone with data-sovereignty rules to follow.

Governance model is where the fine print lives, and where most vendors get vague on purpose. Virtual keys, role-based access, budgets, rate limits, per-user policy: these aren't interchangeable checkboxes, and the real question is whether they're enforced at the gateway itself or pushed back down to individual servers to handle inconsistently, each in its own way. Protocol support matters just as much. STDIO, HTTP, SSE, and Streamable HTTP are all in active use across real deployments right now, and a gateway that drops one of them opens a compatibility hole somewhere in the stack, usually the place you least expect.

Authentication depth separates the serious options from the shallow ones. OAuth 2.1, PKCE, dynamic client registration, per-user OAuth flows, each covers a different threat, and thin auth support leaves exactly the gap attackers go looking for first. And there's ecosystem fit: does the gateway actually work with Claude Desktop, Cursor, Claude Code, VS Code, GitHub Copilot, the tools people are already using today. A gateway that only works in theory isn't worth much in practice, and vendors know this, which is why the demos always work.

A few names worth knowing here. Kong added MCP support to its AI Gateway in late 2025 through an MCP Proxy plugin, a natural move for anyone already running Kong for API management, now governing LLM, MCP, and agent-to-agent traffic from one place. TrueFoundry routes all tool discovery through the gateway itself, using identity and policy context so agents never talk to MCP servers directly; it's shown up in a Gartner Market Guide for AI Gateways, for what that's worth. Bifrost, from Maxim AI, ships something called Code Mode, where instead of calling tools one at a time, the AI writes Python to orchestrate several MCP servers together inside a sandbox, with audit logging built for SOC 2, GDPR, HIPAA, and ISO 27001.

MintMCP is built specifically for enterprise MCP governance, SOC 2 Type II audited, with HIPAA compliance and a BAA available for anyone who needs one. Cloudflare has stitched its AI Gateway, MCP Server Portals, and existing Gateway product into one security plane, a fit for anyone already living on Cloudflare's edge who wants that same footprint covering agent traffic too. It's aimed at teams who want discovery, governance, and observability as one system instead of five tools stitched together with duct tape and hope.

Identity integration isn't optional at real scale. Fine-grained, role-based permissions tied to an existing identity provider, whether that's Okta, Entra ID, SAML, or OIDC, are the only realistic way to enforce access policy across a workforce numbering in the thousands.

Building an MCP inventory program that can actually be maintained

There's no finish line here, and anyone who tells you otherwise is selling something. MCP servers get created every time a team adopts a new AI tool, so treat inventory the way you'd treat patch management: ongoing infrastructure, not a project you close out and file away and forget.

Start by building a system of record before enforcing any policy at all. An ungoverned list beats no list, since it gives you a baseline; without one, you can't even tell when something new shows up in your own environment. Apply the same instinct regulated environments already use for permissions generally: access should be scoped to a project, a task, or an environment. Broad, standing access that never expires deserves a hard look, not a shrug and a "we'll get to it."

For teams starting from zero, the order matters more than people expect. Run static discovery first, across infrastructure-as-code, containers, and repositories, to catch what's been declared. Then layer dynamic scanning on top to catch what's running that never got declared anywhere, and check external exposure as its own separate step, since internally-focused tools walk right past a server sitting wide open to the internet. Audit every server you find for hardcoded credentials before it touches any governance policy at all. Then route every sanctioned server through a governed gateway before an agent gets anywhere near it; that's the step that actually turns a list into control instead of documentation.

Leadership doesn't need convincing with theory here, which helps. Shadow AI incidents are already a documented, growing category of enterprise risk, and an MCP inventory program is a concrete, auditable thing you can point to that shows active governance instead of a scramble after something breaks on a Friday afternoon. Cost tracking, usage logs, and audit trails need to be built into the governed layer from day one, not bolted on later, because reconstructing what an agent actually did after the fact is rarely possible if nobody logged it at the time.

A mature program looks like this: every MCP server in the environment is known, classified by what it can reach, routed through a central policy layer, and watched for behavior that doesn't match its pattern. That's the same bar enterprises already hold APIs and SaaS access to; nobody would accept an unmanaged SaaS sprawl problem in 2026 and shrug it off. MCP just hasn't caught up yet. Until it does, the inventory gap is the whole game.