MCP Gateway Registry: Cataloguing Servers and Tools Safely

An MCP gateway registry is the catalogue of servers and tools a gateway is allowed to expose, with an owner, a risk label and a change history for each entry. Keep one so you can answer what is connected, who approved it and what changed, and vet every entry before it reaches an agent.

Two meanings of registry

The term covers two things, and confusing them leads to bad decisions.

• A public directory of MCP servers where publishers list what they offer. Its job is discovery.
• An internal registry that belongs to your gateway. Its job is control: the list of servers and tools you have decided to expose.

A public listing is a lead. An internal entry is a decision. This article is about the second.

What a registry looks like in real gateways

Registration is a real feature in gateway projects, not an abstraction. The Microsoft mcp-gateway README describes a control plane that manages adapters and tools through REST APIs, with metadata stored in Redis for local deployments and Cosmos DB for cloud ones, and a tool gateway router that dispatches tool calls to registered tool servers. Registration is how a server becomes reachable.

BusinessMCP’s hosted endpoint takes a different approach. Its hosting page says it can aggregate third-party MCP servers, re-registering their tools on your endpoint under an ext_ prefix, and its published tool catalogue counts 115 platform tools and 48 from connected services, generated from its live registry. The common idea is the same in all of them: a place that says what exists.

The fields to record

Field	Why it matters
Server name and URL	Identity and where it runs
Owner	Who answers questions and approves changes
Purpose	Why it is connected at all
Transport	Streamable HTTP, SSE or stdio, and how it authenticates
Tool list with descriptions	The surface an agent will read and act on
Risk class per tool	Read, write or irreversible
Data touched	Customer data, finance, internal documents
Version or hash	To detect silent changes
Approved by and date	Accountability
Review date	Prevents drift

Key takeaway: the registry is the record of decisions. If a tool is reachable but not in the registry, treat it as an incident.

Vetting an entry before it goes in

A server is not safe because someone published it. Run a short intake.

1. Provenance. Who maintains it? Is the code inspectable? What is the licence?
2. Tool descriptions. Read every description as if you were the model. Hidden instructions inside them are the basis of tool poisoning.
3. Permissions. What credentials does it need and what could they do?
4. Network behaviour. Does it fetch URLs or call out? If it does, does it guard against server-side request forgery?
5. Transport and auth. Does it speak a supported transport and require authentication?
6. Failure behaviour. What does it return on error, and could errors leak secrets?
7. Update policy. How will you hear about changes?

BusinessMCP’s guide to MCP prompt injection covers the poisoning, shadowing and rug-pull risks that make step 2 and step 7 matter, and lists the mitigations: keep the connected set small, pin versions and verify integrity.

Namespacing: avoiding collisions and confusion

When several servers feed one gateway, tool names can collide. Two servers might each offer search or create_task. Without a convention, the model cannot tell them apart and you cannot tell which one acted. Namespacing prefixes each tool with its server, which solves both problems. The BusinessMCP hardening utilities repository includes a helper that prefixes tool names with the server name and, when a name must be truncated, appends a hash to avoid collisions. The hosted product’s ext_ prefix is the same idea in practice.

Namespacing also helps your allowlists, because policy can match a prefix, and your audit logs, because a call to crm_update_contact names its source.

Handling change

Tools change. Descriptions get edited, parameters are added, behaviours shift. The registry should therefore track a version or content hash for each tool description and flag differences. When a change is detected:

1. Pause the tool for sensitive keys.
2. Diff the new description against the approved one.
3. Re-run vetting for anything that changed materially.
4. Require re-approval from the owner.
5. Update the registry and log the decision.

This is a defence against rug pulls, where a server passes review and then changes.

Keeping the registry small

A large registry is a large attack surface. BusinessMCP’s security guide recommends keeping the tool count small and removing tools you do not use, and notes that its platform caps the total connector tools per workspace. Whether or not your platform enforces a cap, set one yourself and review it every quarter.

Registry health check	Healthy	Unhealthy
Every entry has an owner	Yes	Orphaned entries
Every tool has a risk label	Yes	Unlabelled tools
Last review within 90 days	Yes	Stale entries
Unused tools removed	Yes	Everything ever connected still reachable
Changes detected and approved	Yes	Silent updates

Ownership and the review rhythm

A registry fails quietly when nobody owns it. Name one team as the registry owner, and name an owner for every entry. The registry owner maintains the template, runs the review cycle and has the authority to disable an entry. Entry owners answer questions about their server and approve changes to it.

A quarterly review is a reasonable starting rhythm. For each entry, ask four questions: is it still used, is the owner still the right person, has anything changed since approval, and do the risk labels still hold? Remove what fails. Removal is the cheapest security improvement available, because an unused tool cannot be abused.

It also helps to separate environments. A development registry can be permissive so engineers can experiment. A production registry should require review for every addition. Moving an entry from one to the other is a deliberate step with its own approval, and it should carry the vetting notes with it.

Finally, connect the registry to your keys. Each key’s policy should refer to registry entries, not to ad hoc tool names. That way, when an entry is disabled, every key that depended on it loses access in one move, and your key inventory shows exactly which agents are affected. Without that link, you end up chasing individual keys during an incident.

Using public directories wisely

Public registries are useful for finding candidates. Treat their listings the way you would a search result. Check the publisher, read the code if it is open and trial the server in a sandbox before you add it to your gateway. Never add a server to production because its listing looks tidy.

Where this fits

The registry feeds the rest of your controls: allowlists decide who may call what, security practices set the baseline, and the evaluation checklist helps you judge whether a gateway’s registry features are strong enough. Review it on a schedule, and treat additions as changes that need an owner.