{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreih23dxetxumorgu2awl76mdrrxhx6jiwia5xt5ayrhpqz3rohtvya",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpl2bdd6ofa2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreif2hueyiqxrznymjjvjhrqdx522vlhhp2uiy3v2sfqou3jjgu5vne"
    },
    "mimeType": "image/webp",
    "size": 64706
  },
  "path": "/sahajmeet_kaur_/what-is-an-mcp-registry-and-the-nxm-problem-it-solves-4ogm",
  "publishedAt": "2026-07-01T07:35:26.000Z",
  "site": "https://dev.to",
  "tags": [
    "ai",
    "llm",
    "devops",
    "mcp",
    "TrueFoundry's MCP Registry and Gateway",
    "@modelcontextprotocol"
  ],
  "textContent": "**TL;DR:** An MCP registry is a centralized catalog of MCP servers - what they do, how to connect, what tools they expose, and who's authorized to call them. Without one, every developer and agent maintains their own copy of that information, credential rotation breaks everything, and access control is nonexistent. With one, tool discovery is dynamic, credentials are managed centrally, and RBAC governs what each agent can see and call. This post covers what it is, how it works, and the specific failure modes it prevents.\n\nThere's a pattern I've seen play out in almost every team that scales past a handful of MCP servers.\n\nThe first few connections feel like magic. You run `npx @modelcontextprotocol/server-github` in a terminal, point Claude Code at it, and your agent can suddenly search repositories. Clean, fast, no glue code. Then you add Jira. Then Confluence. Then a Slack MCP server and an internal data API. Now you have six servers and twelve developers, and each developer has their own `~/.cursor/mcp.json` or `.claude/settings.json` with hardcoded connection details and credentials.\n\nWhen a server endpoint changes, you update twelve config files manually. When a credential rotates, you hunt down every developer who cached it. When a new engineer joins, you spend half a day walking them through which servers exist and how to connect. When someone leaves, you hope you remembered to revoke their individual tokens on each of the six systems.\n\nThat's the distributed sticky-note problem. An MCP registry is the infrastructure that replaces it.\n\n##  What an MCP registry is\n\nAn MCP registry is a centralized catalog that stores metadata about every MCP server in your organization - what it does, how to connect to it, what tools it exposes, what auth method it uses, and who is authorized to access it.\n\nThe analogy that made it click for me: it's to MCP servers what a DNS server is to IP addresses, or what a service registry is to microservices. Instead of hardcoding addresses everywhere, you have one authoritative place that knows where everything is and how to reach it. Components look things up instead of having them embedded.\n\nAt minimum, a registry entry contains:\n\n  * **Server identity** - name, description, owner team, approval status\n  * **Connection details** - endpoint URL, transport type (stdio vs Streamable HTTP vs SSE)\n  * **Auth metadata** - what authentication the server requires and how to obtain credentials\n  * **Tool schema** - what tools the server exposes, what parameters each accepts\n  * **Access policy** - which users, teams, or agents are authorized to connect\n\n\n\nThe separation between connection details and auth metadata is what makes credential rotation cheap. When a GitHub OAuth token rotates, you update one record in the registry. Every agent and developer connecting through the registry picks up the new credentials automatically — no config file hunting required.\n\n##  The N×M problem\n\nThe problem a registry solves has a name in distributed systems: the N×M integration problem.\n\nIf you have N agents and M MCP servers and you connect them directly, you have N×M integration points. Each one needs its own connection config, its own credentials, its own error handling, its own version of \"what happens when the server moves.\"\n\nWith 3 agents and 3 servers that's 9 integration points. With 8 agents and 6 servers it's 48. At 240 engineers and 8 servers - the kind of scale where this becomes a real operational problem - you're maintaining roughly 1,900 config entries by hand.\n\nA registry collapses this. Each server is registered once. Each agent connects to the registry endpoint, declares what it needs, and the registry routes to the right server with the right credentials. N+M integration points instead of N×M.\n\nThe secondary benefit: when a server moves (new URL, new cluster, new transport), you update one registry entry. Nothing downstream breaks.\n\n##  What a registry is not\n\nWorth being explicit because \"MCP registry\" means different things in different contexts:\n\n**The public MCP registry** (the one at `registry.npmmcp.com` or similar) is a discovery catalog — a searchable list of publicly available MCP servers that developers can browse to find tools. It's like an app store listing page. It doesn't authenticate connections, enforce access control, or provide an audit trail. It's a great place to find servers. It's not production infrastructure.\n\n**An enterprise MCP registry** is what this post is about: the privately operated catalog that governs how your specific agents connect to your specific servers, with auth and RBAC and audit logging. Same concept (centralized metadata), different operating context.\n\n**An MCP registry is not a proxy.** A proxy handles transport. A registry handles metadata and policy. In practice, the two are often deployed together — the registry knows about servers, the proxy actually routes traffic to them — but they're distinct components.\n\n##  The governance gap in raw MCP\n\nRaw MCP has no built-in access control. Any agent with a server's connection URL can call any of its tools. A junior developer's agent and a senior engineer's agent have identical access. An over-permissioned sub-agent has the same blast radius as the service account that spawned it.\n\nThe governance layer a registry adds:\n\n**RBAC at the tool level.** Not just \"team A can access the Jira server\" but \"team A can call `search_issues` and `create_issue` but not `delete_issue`.\" The access policy is defined in the registry and enforced before the tool call reaches the server.\n\n**Pre-tool-call visibility filtering.** Agents only see the tools they're authorized to use in the first place. An agent browsing available tools via `tools/list` gets back a filtered list based on its identity — not the full server capability set. This matters: an agent that doesn't know a destructive tool exists can't accidentally call it.\n\n**Centralized credential management.** Users authenticate once to the registry. The registry manages downstream credentials — OAuth tokens for GitHub, API keys for Jira, service account tokens for internal APIs — and refreshes them automatically. Offboarding is one action: revoke the user's registry access. Every downstream system is covered.\n\n**Audit trail per tool invocation.** Every tool call logged: which agent, which user identity, which tool, what parameters, what the response was, at what time. When a security team asks \"which agents accessed the production data API last month,\" it's a query rather than two days of log archaeology.\n\n##  Virtual MCP Servers: the access-scoping primitive\n\nOne concept worth understanding because it's genuinely useful: Virtual MCP Servers.\n\nA virtual MCP server is a curated logical endpoint that exposes a subset of tools from one or more real MCP servers. Instead of giving an agent access to an entire Jira MCP server with all its read and write tools, you define a virtual server called \"finance-readonly\" that exposes only the Jira tools the finance workflow needs — and nothing else.\n\nThe agent points at the virtual server endpoint. It sees a limited, purpose-appropriate tool surface. The actual routing to the underlying server happens inside the registry/gateway layer, invisible to the agent.\n\nThis is the pattern that solves the \"over-permissioned agent\" problem without requiring every agent to implement its own access filtering. The policy lives in the platform, not in the agent code.\n\n##  What we use and where TrueFoundry fits\n\nAfter hitting the credential sprawl problem and a compliance audit that asked for tool call logs we couldn't produce cleanly, we evaluated a few registry options and ended up on TrueFoundry's MCP Registry and Gateway.\n\nThe specific things that mattered:\n\n**Unified credential management.** Developers get a single Personal Access Token for the registry. The registry handles OAuth for GitHub, Jira, Confluence, and our internal APIs — auto-refreshing tokens before they expire. Offboarding became one action instead of six.\n\n**RBAC with identity provider integration.** Access policies connect to our existing Okta setup. When we add a user to the \"data-engineering\" team in Okta, they automatically get the MCP access profile for that team. We stopped maintaining a parallel access list.\n\n**Virtual MCP Servers.** We define one virtual server per team persona. The security team sees Sentry and Datadog tools. Product engineers see GitHub and Jira. Neither sees the other's tool surface, and neither sees the internal data API unless they're explicitly provisioned for it.\n\n**Full audit trail.** Every tool invocation logged with structured metadata. When the compliance question came — \"which agents accessed the production data API in the last 30 days\" — it took ten minutes to answer.\n\nTradeoff worth naming: TrueFoundry is Kubernetes-native, so there's real setup overhead if you're not already on K8s. For a team with two or three servers and five developers, a shared config file is fine. The registry infrastructure pays off when you cross roughly ten servers or twenty developers or when a compliance requirement forces the audit trail question.\n\n##  When you actually need one\n\nThe honest signals:\n\n  * You can't answer \"what MCP servers do we have running right now\" without asking multiple people\n  * A server endpoint change means updating configs on multiple developer machines\n  * A credential rotation cascades into a half-day of finding and updating every place it's referenced\n  * A developer left and you're not fully certain their MCP access was revoked everywhere\n  * A compliance or security team has asked for a log of which agents used which tools\n\n\n\nIf two or more of those describe your situation, the registry conversation is overdue. The distributed sticky-note problem scales as O(developers × servers) - it gets expensive fast.\n\nWhat does your current MCP server management setup look like - are you still on individual config files per developer, or has something pushed you toward a central registry? Would like to hear how teams are handling credential rotation across many servers without a centralized credential store. Drop it in the comments.",
  "title": "What Is an MCP Registry? (And the NxM Problem It Solves)"
}