The second useful server creates the real governance problem
The common story says MCP makes tool-connected AI easier because it standardizes how clients and servers speak. That is true, and it is exactly why governance gets harder after the first success. One approved server quickly becomes several. Different teams add local servers, remote servers, or partner-hosted servers for different workflows, and developers begin to expect the same discovery experience across IDEs, CLIs, and shared assistants. At that point, the question is no longer whether a single integration works. The question is whether the company has a real inventory of which servers are allowed to exist in the first place.
GitHub is turning server discovery into company policy, not personal setup
GitHub now documents MCP server management as an organization and enterprise policy surface. Its MCP management guidance says companies can allow or block MCP usage entirely, or restrict access to a defined list of servers in an MCP registry. GitHub describes that registry as a directory of MCP servers that acts like a catalog for IDEs and Copilot, with each entry pointing to a manifest describing the tools, resources, and prompts the server provides. That catalog is not just convenience. GitHub says the registry lets teams curate discoverable servers, restrict unapproved servers for security and compliance, and give developers clarity when a server is blocked by policy. The operating signal is straightforward: server discovery is becoming part of enterprise control, not just developer preference.
Allowlists now follow the user across tools, which raises the bar for inventory quality
GitHub goes further in its allowlist enforcement documentation by saying the active MCP policy is tied to the organization or enterprise that assigns the Copilot seat, and that the platform resolves to a single active policy and registry when multiple seats are involved. It also says local servers must be included in the registry with the correct server ID when the environment is set to registry-only mode. Microsoft confirms that this governance layer is already surfacing beyond GitHub.com itself. Visual Studio 2026 now respects GitHub MCP allowlist policies, and Microsoft says users can connect only to approved MCP servers when an allowlist is configured. That means a weak registry is not a harmless admin artifact. It becomes the policy object different clients depend on when they decide what tools are even visible.
Google is making MCP inventory a first-class governed catalog
Google is pushing the same operating model in its new Agent Registry work. Agent Registry is documented as a centralized catalog that lets teams store, discover, and govern MCP servers, tools, and AI agents within Google Cloud. Google also says official Google and Google Cloud remote MCP servers are automatically registered, while external or custom MCP servers must be explicitly registered, and tool specifications must be provided for discovery. The Agent Registry MCP server then becomes a shared discovery path for applications such as Gemini CLI, ChatGPT, Claude, and custom clients. This matters because it turns server inventory into infrastructure. Once discovery is centralized, the quality of the registry determines which tools show up, which metadata travels with them, and which identities are trusted to call them.
A registry decides what can exist; approval still decides what may run
A clean server catalog is not the whole control plane. It solves a different problem. OpenAI's current guidance says sensitive actions should require approval, and it separately warns teams to connect to trusted servers hosted by the service providers themselves instead of casually relying on third-party proxies. That creates an important split. The registry or allowlist decides which servers are approved to exist in the shared environment. The approval layer still decides whether a particular action against an approved server should proceed in a given run. Teams that blur those two layers usually end up with a catalog that is too open, approval logic that is too vague, or both.
Executive move: require one MCP server registry contract before broader rollout
Before expanding shared tool-connected agents, require one short MCP server registry contract for each environment. Name the server identifier, owner, hosting operator, official or third-party status, manifest URL, discovery client surfaces, tool classes exposed, authentication model, approval boundary, logging sink, disable owner, and fallback path if the server is removed. Then run one live test: block a server, confirm it disappears or fails cleanly across the approved clients, and verify the team can still explain which workflow lost which capability. If that exercise turns into detective work, the rollout is ahead of its control system.
Key takeaways
- MCP rollout becomes a server-inventory problem as soon as more than one team expects shared discovery across IDEs, CLIs, and assistants.
- GitHub and Microsoft now treat registries and allowlists as enterprise policy objects, while Google is turning MCP server inventory into a centralized catalog and discovery service.
- A registry controls which servers can exist in a shared environment; approval design still controls which actions may proceed on those servers.
Related surfaces
- Enterprise-managed authorization briefing — Pair server-registry governance with the adjacent briefing on centralized IdP policy, revocation, and broad shared access.
- Connector-entitlement briefing — Use the adjacent briefing when the rollout problem shifts from which server is approved to which connected systems and scopes each tool imports.
- About LockedIn Labs — See how the firm frames governed implementation work and why catalog and approval design matter more than integration theater.
- Enterprise delivery model — Review the delivery lane where runtime ownership, review, monitoring, and handoff stay explicit before tools are shared broadly.
- Governed Delivery Loop — Inspect the method for turning one high-risk workflow into a governed implementation path with named proof artifacts.
- Contact LockedIn Labs — Discuss one MCP rollout where teams can connect useful servers but cannot yet explain the approved catalog, discovery path, or disable owner.