MCP Server Discovery in Enterprise Networks
The core constraint is architectural. To learn what an MCP server does, a client must connect and complete a full initialization handshake: initialize, capability negotiation, session establishment. There is no lightweight peek. The wire format is JSON-RPC 2.0, connections are stateful, and every new session triggers an explicit negotiation phase before you know anything useful. REST endpoint discovery is a problem enterprises largely solved with API gateways and OpenAPI catalogs. MCP's stateful session model introduces a category of friction that REST registries never had to contend with.
Transport fragmentation compounds it. The current spec, version 2025-11-25, standardizes two transports: stdio and Streamable HTTP. The earlier HTTP+SSE transport is deprecated. Enterprises running older servers on the deprecated transport introduce version fragmentation into any discovery effort, so a single scan surfaces servers behaving in inconsistent ways depending on which generation of the spec they implement. You are not scanning a homogeneous population. Instead, you are scanning a population mid-migration, and your tooling either handles that gracefully or it misleads you.
The combinatorial math is the part that actually breaks people. Without a discovery layer, configuration burden scales as the product of agents multiplied by servers. Every agent-to-server relationship requires its own endpoint location, authentication configuration, and compatibility verification. Three servers and two agents: manageable. Dozens of each, which happens faster than most platform teams anticipate once agentic adoption accelerates: not manageable, and the accumulating manual overhead is where governance quietly collapses.
Any discovery approach that relies entirely on runtime handshakes cannot scale past early experimentation. You need a metadata layer that lives outside the live connection itself, one that can answer "what exists and what does it do" before a session is established.
The Technical Approaches Enterprises Are Actually Using to Discover MCP Servers
Four distinct mechanisms address different parts of the discovery surface, and enterprises managing this well typically deploy more than one. No single mechanism covers the whole picture.
The official public registry, launched in September 2025, is an open catalog and API for publicly available servers. It stores metadata about endpoints, transport protocol support, and authentication requirements. It does not proxy or mediate runtime traffic; it is a directory. Namespace authentication via GitHub, DNS, or HTTP challenges limits spam but does not enforce enterprise access policy. For discovering public and open-source servers, it is genuinely useful. For governing an internal server estate, it was not designed for that job.
SEP-2127 settles on /.well-known/mcp.json as the canonical path for pre-connection metadata. A simple HTTP GET returns structured information: description, tool listings, capabilities, authentication requirements, everything a client needs before deciding whether to connect, without completing a full MCP handshake. The path follows RFC 8615 conventions, so it fits cleanly into existing web infrastructure. Neither SEP-2127 nor the underlying Server Card specification was finalized as of June 2026, but the Working Group was active with sessions running through August 2026, led by contributors from Anthropic and GitHub. Claude Desktop and Cursor were already shipping MCP v2.1 with Server Card support as of April 2026. The practical value is real: a client that knows a server's tools before connecting can filter rather than loading everything, which also addresses the token bloat problem that surfaces when agents enumerate large tool registries without discrimination.
DNS-based discovery is a simpler bootstrap mechanism. A single mcp TXT record lets an agent discover an organization's entire MCP ecosystem from a domain name alone, following established patterns like dmarc and _acme-challenge. Community prototypes exist; no formal specification has been adopted. Useful for initial orientation, not for runtime governance or continuous audit.
The registry-as-MCP-server pattern is elegant precisely because it requires no new primitives. When the registry itself is an MCP server, agents discover and call it exactly as they would any other server. A discovery client connects to servers found in the registry, indexes their tools once, and routes subsequent calls without repeating the listTools() round trip on every invocation. It works entirely within the existing agent tool-calling model, which keeps adoption friction low.
DNS bootstraps initial discovery. Server Cards provide pre-connection metadata. A registry indexes and routes. A gateway enforces. Organizations that piece these together intentionally are the ones that avoid the chaos that comes from treating discovery as an afterthought.
Why the Public Registry Alone Is Not Enough for Enterprise Environments
The official public registry was designed for ecosystem growth: open publication, open discovery, no access control. That design is appropriate for its purpose and entirely wrong for governing internal tool estates. The gap between those two purposes is not subtle, and conflating them is one of the more consequential mistakes an enterprise platform team can make.
The requirements the public registry fails to address are not edge cases. Per-environment separation is a baseline need; development agents must see different tools than production agents. Allowlisting, restricting which servers agents may connect to within an organization, is a security fundamental. Policy-based visibility, where some teams see servers others cannot, is routine access control. And audit trail, recording who connected to what, when, and what operations were performed, requires a layer that mediates runtime traffic. The public registry does not mediate runtime traffic.
Enterprise registries exist to add exactly these layers. The architectural distinction that matters is between the registry as discovery mechanism and the gateway as enforcement mechanism. Both are necessary. Neither substitutes for the other, and the organizations that conflate them typically discover the gap during an incident rather than before one.
Kong Context Mesh, announced in February 2026, illustrates where the market is moving: automatic discovery of enterprise APIs, transformation into agent-consumable tooling, and registration with an enterprise MCP registry, treating discovery and governance as a combined product layer rather than a manual configuration exercise. MCP Manager, built by Usercentrics, takes a similar posture, combining an enterprise registry with gateway-enforced access controls, real-time observability, and role-based access control for agent identities. These products exist because enterprises were clearly building this functionality by hand before purpose-built tooling arrived, and hand-built governance does not hold under scale.
Gartner's January 2026 analysis estimated that failure to close the agent integration gap puts a substantial share of agentic AI initiatives at risk of cancellation by 2027. The integration gap is not primarily a model capability problem. It is an infrastructure problem, and discovery is the part of that infrastructure most organizations have not actually solved.
The Shadow MCP Problem: Servers That Exist Outside Any Registry
Shadow MCP is the 2026 version of shadow IT, and it has the same root cause: when the governed path is slower or more painful than the ungoverned path, people take the ungoverned path. Employees deploy MCP servers without IT oversight, give AI agents access to production systems and databases, and the security team never maps those connections. A 2026 Gravitee survey found that only a minority of organizations have full visibility into which AI agents are communicating with each other. That means most enterprise environments contain agent-to-server connections that have never been scoped or approved by anyone with security responsibility.
Servers outside any registry are servers an organization cannot enforce policy on, cannot audit, and cannot rotate credentials for. Early 2026 research documented a meaningful number of active MCP servers on the public internet with no authentication whatsoever; a portion of those are enterprise-connected tools that developers stood up and left running, often without realizing the exposure they created. The ungoverned server is the attack surface.
The instinct to respond by banning MCP server deployment outside IT approval does not solve the problem. It relocates adoption to personal laptops, personal accounts, and endpoints the security team cannot observe. A governed path that is genuinely faster and easier than the workaround reduces shadow adoption more effectively than a blocked path does.
OWASP published a dedicated MCP Top 10 in late 2025. The risks most directly tied to undiscovered servers involve ungoverned tool access and unaudited data flows, not model behavior. This is an infrastructure blindness problem, not a model problem. Every MCP server added without a registry entry is an identity the organization cannot account for, and unaccounted identities are the ones that get exploited.
Identity and Authentication Gaps That Discovery Alone Does Not Close
Discovery tells you a server exists. Authentication tells you who is allowed to reach it and under what conditions. Both are required for governance, and knowing where something lives is not the same as controlling who can use it.
Only 23% of organizations had a formal enterprise-wide agent identity strategy as of February 2026, according to CSA and Strata research. Less than a fifth were highly confident their identity and access management infrastructure could handle agent identities at all. Until June 2026, the standard MCP authorization model required every employee to manually authenticate to every MCP server individually. Security teams had no mechanism to enforce consistent access policy across that landscape, and no centralized audit trail existed by default. That exposure was running quietly in production at most enterprises that had adopted agentic AI at any meaningful scale.
MCP Enterprise Managed Authorization reached stable status on June 18, 2026. It replaces per-user OAuth consent screens with a zero-touch, IdP-delegated flow, with Okta as the first supported identity provider. The current spec for remote servers on HTTP transports mandates OAuth 2.1 with PKCE S256, RFC 9728 for authorization-server discovery, RFC 8707 Resource Indicators, and RFC 7591 Dynamic Client Registration. Organizations running older implementations are outside the current security baseline, not because they made a bad decision, but because the specification matured faster than most deployment cycles could track.
The capability that actually matters for incident response is On-Behalf-Of token propagation. Without it, an audit log records "gateway service account called database write tool." With OBO, the log records a named user calling a specific tool at a specific time from a specific agent session. The difference between those two outcomes is an infrastructure decision made at the identity and gateway layer, and it needs to be made before the incident, not reconstructed afterward.
Role-based access control for AI agents ensures that what AI can do reflects a deliberate organizational decision, not a set of capabilities that accumulated by default because no one built a mechanism to limit them.
Building Discovery as an Ongoing Operational Discipline, Not a One-Time Scan
A one-time network scan finds servers that exist today. It will not find the server a developer adds tomorrow, or the one a vendor pushes in a dependency update, or the one that surfaces when a new team adopts an agent framework without coordinating with the platform team. Scan-and-forget is a starting point with a very short shelf life.
The operational model that actually holds looks like this: automated registration at deployment time, continuous reconciliation between what the registry says and what network traffic shows, and alerting when those two pictures diverge. The registry has to be a living document. Every new server requires an entry at the moment of deployment, not as a retrospective compliance step weeks later. The entry is what makes the server governable; without it, you have infrastructure that exists but that no one can actually control.
Four enterprise deployment topologies create meaningfully different discovery requirements. Single-tenant deployments for isolated internal teams are the simplest to inventory. Multi-tenant, row-isolated deployments typical of SaaS-style architectures require the registry to track tenant-scoped server visibility. Federated gateway deployments in large organizations with central audit requirements need discovery that aggregates across gateway instances without losing provenance. Edge-cached, read-only deployments optimized for high-volume tool discovery must ensure that caching posture does not create stale inventory reflecting a past state rather than the current one. These are not hypothetical variations. They are the actual shapes organizations find themselves in, and each one requires slightly different tooling around the registry to function correctly.
Stateful session management introduces a specific complication worth naming directly. Streamable HTTP sessions assume the client consistently reaches the same server instance. Load balancers and proxies can obscure how many distinct server instances actually exist, which means a registry count may underrepresent the actual running population. The Transports Working Group is actively working on stateless session handling across multiple instances; organizations relying on session affinity today should track that work.
Real-time visibility matters more than historical logs for operational governance. An audit log read after an incident is a postmortem. A registry and gateway that surface ungoverned connections as they appear are a safety net. Organizations that build discovery into the deployment pipeline, not as a gate that slows teams down but as the mechanism that gives teams the clearance to say yes to production, ship agentic AI faster than organizations that defer governance until the environment is already complex.
What a Governed MCP Discovery Infrastructure Looks Like in Practice
Three layers make discovery operationally durable. Each does a distinct job, and none of them substitutes for the others.
The registry layer is a central catalog of every approved server, carrying metadata: transport type, authentication requirements, owning team, environment assignment. It is the source of truth for what should exist. The gateway layer is the enforcement mechanism: it routes agent traffic, applies access policy, propagates identity via OBO token flows, and logs at the tool-call level. It is the source of truth for what is actually happening right now. The reconciliation layer performs continuous comparison between registry state and observed traffic, with alerting when unregistered servers appear in traffic or registered servers go silent. That is the mechanism that catches drift before drift becomes exposure.
MCP Manager, built by Usercentrics, reflects this architecture as a purpose-built enterprise control layer: an enterprise MCP registry, gateway-enforced access controls, real-time observability, and RBAC for agent identities, designed for organizations that need to expand agentic AI without accumulating ungoverned surface area as a byproduct.
For organizations earlier in the maturity curve, the starting point is simpler than the full three-layer architecture suggests. Stand up an enterprise registry before the third MCP server is deployed, not after the thirtieth. Require Server Card support, meaning a valid /.well-known/mcp.json response, for any internally deployed server. Gate production deployment on registry entry and authentication configuration; not as a bureaucratic checkpoint, but as the mechanism that makes the server reachable through governed channels in the first place.
The organizations that end up with governable MCP environments are the ones that started with a registry entry and an auth requirement on day one and held that line as the environment grew. A server without a registry entry is a server the organization does not actually control, regardless of who wrote the code or what it was supposed to do.
