Governance · build guide
Enterprise MCP Registry: Centralising Approved Servers and Tools
An inventory records what exists, including the things you would rather did not. A registry records what is approved — which is only meaningful if approval is enforced somewhere other than in the registry.
The short answer
An enterprise MCP registry is the internal catalogue of servers and tools that are approved for agents to use, with an owner, a risk class, a pinned version and an entitlement list against each entry. It differs from an inventory, which records everything discovered, and from a gateway, which enforces the registry’s decisions at call time. A registry with no enforcement point behind it is a wiki page that ages. Four approval states, twelve fields, and one design decision that determines whether engineers use it or route around it.
Registry, inventory, gateway: three jobs
These three get conflated in vendor material and it costs teams real months, because each one solves a problem the others do not touch. Hold the distinction and the architecture becomes obvious.
Inventory — what exists
The discovery output. Includes the unowned server in a developer’s config file and the one nobody remembers buying. Deliberately unfiltered; its value is completeness. See MCP server inventory.
Registry — what is approved
The governance artefact. A filtered, curated subset with an owner, a risk class, a pinned version and an entitlement list per entry. Its value is that somebody said yes, on the record, on a date.
Gateway — what actually happens
The enforcement point. Reads the registry at call time and refuses anything not in it. Without this, the registry describes an intention rather than a state.
The order matters: inventory produces the candidate list, intake promotes candidates into the registry, the gateway makes the registry binding. Skipping straight to a registry produces a beautifully maintained document that no agent has ever consulted.
Four states, not two
Approved and not-approved is too coarse to survive real use, because the interesting cases are all in between. Four states cover everything we have needed and no team has yet asked for a fifth.
| State | Meaning | What the gateway does |
|---|---|---|
| Approved | Reviewed, owned, pinned, risk-classified. Available to entitled agents. | Routes, subject to entitlement and policy. |
| Restricted | Approved for a named set of agents or a named environment only. Most write-capable servers live here permanently. | Routes only for listed identities; refuses and logs otherwise. |
| Pending | In intake. Somebody wants it; review is not finished. | Refuses, with a message naming the intake ticket. |
| Deprecated | Being removed. Existing callers get a deadline; no new entitlements. | Routes with a warning event, refuses after the sunset date. |
Restricted is the state that does the work. Teams reach for approved/denied and then discover that almost everything useful is fine for two agents and alarming for the other nine. Without a restricted state, that pressure resolves as blanket approval — every time.
Twelve fields per entry
The inventory record plus the fields that only exist once somebody has made a decision. If a field cannot be filled, that is the finding: an entry with no owner or no risk class should not be in Approved.
- 01Server name, endpoint and transport. stdio and HTTP have different blast radii; record which.
- 02A named human owner and a named deputy. Team aliases do not make decisions.
- 03Approval state and the date it entered that state.
- 04Reviewer and review date. Who said yes, and when it stops being current.
- 05Pinned version, plus the upgrade policy. Auto-updating third-party servers change tool descriptions without review.
- 06Full tool list, from a live tools/list call, with each tool’s mutating flag.
- 07Risk class per tool, not per server — see tool risk scoring.
- 08Credential and true scope on the backing system, at its widest.
- 09Entitlement list: which agent identities may see and call this, and which tools within it.
- 10Approval requirements: which tools require a human decision, and at what parameter threshold.
- 11Data classification of what flows through: PII, payment data, regulated records, or none.
- 12Sunset date or next review date. Every entry expires; entries that never expire become fiction quietly.
Intake in five steps
Intake is the only part of a registry programme that reliably fails, and it fails the same way every time: it becomes slower than the workaround. Target two working days end to end and design backwards from that.
Claim ownership
A named person accepts the server. No owner, no intake — and this single rule removes roughly a third of requests, because a surprising number of proposed servers turn out to be somebody’s experiment.
Enumerate the real surface
Call tools/list and record what it advertises, not what the README says. Flag every mutating tool. For a third-party server, snapshot the tool descriptions: this snapshot is what you will diff on upgrade, and it is the cheapest supply-chain control available.
Scope the credential
Establish what the server’s credential can do on its backing system at its widest. Reduce it before approval, not after. This is the step that takes calendar time, because it needs the system owner to agree.
Everything downstream is cheaper against a smaller worst case — how to secure an MCP server works through why this is step one there too.
Classify and set entitlement
Assign a risk class per tool, decide which agents get access, and set approval thresholds for the mutating tools. Default entitlement is nobody; access is granted, never inherited.
Pin, register, route
Pin the version, write the entry, and only then open the route. Registration is how the route gets opened — that coupling is the entire mechanism keeping the registry honest.
The one design decision that determines adoption
Registries fail for a single reason: using them is slower than not using them. Every successful internal registry we have seen makes registration the fastest path to what the engineer actually wanted, which is a working route and a credential.
That means the registry cannot be a separate documentation system maintained out of duty. It has to be the thing that issues the route. If an engineer can get a working connection without touching the registry, some will, and the ones who do will be the ones under the most delivery pressure — which correlates uncomfortably well with the servers you would most want reviewed.
Practical consequences: intake completes in days not weeks, the registry is queryable by API rather than only by human, entries are editable by their owner without a ticket, and the gateway reads it live rather than from a nightly export. None of these are hard; all of them get dropped when a registry is treated as a compliance deliverable rather than as infrastructure.
The counter-test is simple. Ask an engineer who joined last month to add a server. If they finish without asking anyone how, the registry works.
Built on this thinking
A registry only binds if something reads it at call time
Barzel Central Gateway makes registration the route: entries carry owner, risk class, pinned version and per-tool entitlement, and the gateway refuses anything not approved for the calling identity — logging the refusal. Registry, policy, routing and evidence in one place rather than four.
Five mistakes worth naming
Registry with no enforcement
The most common and the most expensive. Nothing reads it, so nothing depends on it, so it decays — and it decays invisibly.
Server-level entitlement
Entitlement at server granularity grants the mutating tools along with the read ones. Grant at tool level or you have not really granted anything specific.
No restricted state
Approve/deny forces a binary on inherently conditional cases, and the pressure always resolves towards approval.
Entries that never expire
A review date is what separates a registry from an archive. Expire everything, even the boring entries.
Free-text risk
Risk as prose cannot be queried, sorted or enforced. Use a small fixed set of classes and accept the loss of nuance.
Frequently asked questions
What is an enterprise MCP registry?
The internal catalogue of MCP servers and tools approved for agents to use, recording a named owner, a risk class, a pinned version and an entitlement list against each entry. It is the governance artefact built from an inventory, and it is only binding if an enforcement point reads it at call time.
What is the difference between an MCP registry and an MCP inventory?
An inventory records everything discovered, including servers nobody approved. A registry records what has been reviewed and approved, with an owner and a date. The inventory is the candidate list; the registry is the decision.
What is the difference between an MCP registry and an MCP gateway?
The registry holds the decisions; the gateway enforces them at call time. A registry without a gateway describes an intention. A gateway without a registry enforces whatever was hard-coded into it.
What states should a registry entry have?
Four: Approved, Restricted, Pending and Deprecated. Restricted is the one that matters — approved for a named set of agents or environments only. Without it, conditional cases resolve as blanket approval every time.
What should an MCP registry record about each server?
Twelve fields: name, endpoint and transport; a named human owner and deputy; approval state and date; reviewer and review date; pinned version and upgrade policy; the live tool list with mutating flags; risk class per tool; credential and its true scope; entitlement list; approval thresholds; data classification; and a sunset or next-review date.
How do you stop engineers from bypassing the registry?
Make registration the fastest path to a working route. If a credential and a connection can be obtained without touching the registry, the teams under the most delivery pressure will do exactly that. Couple registration to route issuance and the incentive inverts.
Should entitlement be granted per server or per tool?
Per tool. Server-level entitlement hands over the mutating tools along with the read-only ones, which is almost never what the approver intended.
How long should MCP intake take?
Two working days end to end is the target. Beyond that, the workaround becomes faster than the process and adoption collapses — ownership and credential scoping are the two steps that consume the time, and both need a decision rather than engineering.
Sources and further reading
The general requirement for an approved-software catalogue is old and well documented; the sources below state it. The MCP-specific states, fields and intake sequence are our own, from operating five published servers and reviewing third-party ones.
- 01 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 02 · MCP projectModel Context Protocol — official documentation ↗Primary source for protocol structure, transports and the shape of a tools/list response.
- 03 · Center for Internet SecurityCIS Critical Security Controls ↗Control 1 and 2 — inventory of assets and software — restated here for MCP servers and tools.
- 04 · OpenSSFSLSA — Supply-chain Levels for Software Artifacts ↗Provenance and reproducibility framing for third-party server intake.
- 05 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 06 · ISOISO/IEC 42001 — AI management systems ↗The management-system standard auditors increasingly map AI governance evidence against.
- 07 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
Last reviewed 24 August 2026. External links open in a new tab; we do not control their content.
Try the mechanics on a live server
To watch a real tools/list response before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
Barzel Central Gateway is this layer, sold as a running product
Twenty-five tools covering identity-aware policy, tool routing, risk scoring, approvals, routebooks, workflow simulation and SIEM evidence. Ten policy inputs, six enforcement outcomes, per-user OAuth/OIDC. The Community tier is free, so the evaluation costs an afternoon rather than a purchase order.
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.