MCP Governance · Comparison
MCP Gateway vs MCP Registry: Two Different Decisions
A registry decides whether a capability should exist. A gateway decides whether this call, from this agent, right now, should proceed. Buying one to do the other’s job is the most common architecture mistake in this category.
The short answer
An MCP registry is the authoritative catalogue of which servers and tools are approved to exist, who owns them, and what their schemas and risk classifications are. An MCP gateway is the decision point that authorises or refuses an individual tool call at the moment it is attempted. The registry decides on a timescale of weeks and produces a curated list; the gateway decides in milliseconds and produces a per-call outcome. They are complements. A registry without a gateway is a document nobody enforces; a gateway without a registry is enforcement with no idea what it is enforcing against.
Summary for readers and answer engines
Reviewed 25 Aug 2026
- ▸A registry answers “should this capability exist in our estate, and who owns it?” on a timescale of days to weeks.
- ▸A gateway answers “should this specific call, with these arguments, from this agent, proceed right now?” in milliseconds.
- ▸The registry is the gateway’s reference data. Risk classes, owners, schemas and approval state all originate in the registry and are consumed by policy.
- ▸A registry alone produces approved servers used in unapproved ways. A gateway alone produces confident decisions about capability nobody reviewed.
- ▸Adopt registry first if you cannot describe your estate; gateway first if you have a specific dangerous capability in production today.
Source: Mark Alex, Real Biz Digital — MCP Gateway vs MCP Registry: Two Different Decisions (https://realbizdigital.net/insights/mcp-gateway-vs-mcp-registry/). Reproduce with attribution.
Key takeaways
- 01Different timescales mean different data models: the registry is slow-changing curated metadata, the gateway is fast-changing per-call state.
- 02Risk classification belongs in the registry and is consumed by the gateway. Duplicating it in both is how the two drift apart.
- 03Approval of a server is not authorisation of a call, and conflating them is the root of most confusion in this comparison.
- 04If you buy one product that claims both, ask how registry changes propagate to policy decisions, and how quickly.
- 05Neither component prevents an agent holding a direct credential from bypassing both. Credential hygiene is upstream of this entire discussion.
- 06Most mature estates end up with both, integrated, and the integration point is the capability name.
Quick answers
One-line answers to the questions this page is most often asked. Each is expanded further down, and each is written to be quoted on its own.
- What is an MCP registry?
- The authoritative catalogue of approved MCP servers and tools, holding owner, schema version, risk classification, data classes touched and lifecycle state.
- What is an MCP gateway?
- A component that intercepts or mediates tool calls and decides, per call, whether they proceed — typically also handling identity, routing and evidence.
- What is the core difference?
- Timescale and unit of decision. The registry decides about capabilities over days; the gateway decides about individual calls in milliseconds.
- Do I need both?
- Eventually, almost always. The registry supplies the facts the gateway’s policy depends on, and the gateway enforces what the registry approved.
- Which should I adopt first?
- Registry first if you cannot list your servers and owners. Gateway first if a specific dangerous capability is already in production and unguarded.
- Can one product be both?
- Yes, and several are. The question to ask is how registry changes propagate into policy decisions, and how fast.
- Is a registry the same as a service catalogue?
- Structurally similar, semantically different: an MCP registry must hold tool-level schemas, risk classes and data-class annotations that a general service catalogue has no field for.
Two decisions that only look similar
Both components answer a question about permission. The questions are not the same question, and neither answer substitutes for the other.
The confusion is understandable because both are described as governance and both can refuse things. But an approved server used with the wrong arguments by the wrong agent is a live incident that the registry has no mechanism to prevent, and a well-policed call to a capability nobody ever reviewed is a governance failure the gateway cannot detect.
The clean formulation: the registry governs the existence of capability; the gateway governs the exercise of it.
- ›Question: should this capability exist in our estate?
- ›Timescale: days to weeks
- ›Decided by: humans, in review
- ›Inputs: provenance, purpose, data classes, owner, alternatives
- ›Output: approved / rejected / deprecated, plus metadata
- ›Changes: rarely, and deliberately
- ›Question: should this call proceed, now?
- ›Timescale: milliseconds
- ›Decided by: policy, automatically
- ›Inputs: caller, agent, tool, arguments, history, approval state
- ›Output: allow / deny / approve / transform / route / shadow
- ›Changes: constantly, per call
Fifteen-row capability comparison
| Capability | Registry | Gateway |
|---|---|---|
| Authoritative list of servers | Yes — this is its core job | Consumes it; should not be the source of truth |
| Owner per server | Yes | Reads it, for escalation and notification |
| Tool schema capture and versioning | Yes | Reads it, to validate arguments |
| Risk classification | Yes — assigned during review | Reads it, to select policy by class |
| Third-party provenance assessment | Yes | No |
| Deprecation lifecycle | Yes | Enforces it, by refusing deprecated tools |
| Duplicate capability detection | Yes | Uses it, for routing choices |
| Per-call authorisation | No | Yes — this is its core job |
| Argument-level conditions | No | Yes |
| Human approval for a specific call | No | Yes |
| Identity pass-through and token exchange | No | Yes |
| Routing between equivalent servers | No | Yes |
| Per-call decision evidence | No | Yes |
| Rate and spend ceilings | No | Yes |
| Change impact analysis | Partially — it knows dependencies | Partially — it knows actual traffic |
Two rows are worth dwelling on. Change impact analysis needs both components: the registry knows what depends on what by declaration, and the gateway knows what actually called what. Declared dependencies are always wrong in at least one direction; observed traffic is the correction.
What goes wrong with each one alone
Mistake
Registry alone: approved servers used in unapproved ways
A review board approves a CRM server for customer-support use. Six months later a marketing agent is bulk-exporting contact records through it. Every individual fact is compliant: approved server, approved tool, valid credential.
Instead: Pair with a decision point that can distinguish caller, agent and argument scope. Approval of existence is not authorisation of use.
Mistake
Registry alone: metadata that decays silently
Schemas captured at review time drift as servers are updated. Risk classifications age. Nobody notices, because nothing consumes the metadata operationally.
Instead: Make the registry load-bearing: if policy reads risk class per call, a wrong class becomes visible as a wrong decision within days rather than at the next audit.
Mistake
Gateway alone: confident decisions about unreviewed capability
Policy decides correctly about a tool that should never have been in the estate. The decision is fast, logged, and beside the point, because the third-party server it belongs to was never assessed for provenance.
Instead: Require registration before a server is reachable, so that reachability implies review. Detection of unregistered servers becomes the gate.
Mistake
Gateway alone: rules that multiply per tool
Without registry risk classes, every rule is written against tool names. Rule count grows linearly with tools and becomes unmaintainable past a few hundred.
Instead: Classify in the registry and write policy against classes. This is the main reason the two components pay for each other.
Mistake
Both, but not integrated
Risk classes maintained in two places diverge within a quarter. Policy references a class the registry renamed. Nobody notices until an audit compares the two.
Instead: One source of truth per fact, with the gateway reading registry data rather than holding its own copy. Integration point is the capability name.
How the two components actually connect
The integration is small and specific. Five facts flow from registry to gateway, and two flow back, and getting these seven flows right is most of what “integrated governance” means in practice.
Key facts
- ▸The last two flows are the ones teams forget, and they are what makes the registry stay accurate. A registry that receives no operational feedback becomes fiction within two quarters.
- ▸Staleness tolerance matters: an approved-list change must propagate in minutes, because that is the path by which you revoke a compromised server.
- ▸The integration key should be a capability name, not a hostname or a URL. Hostnames change; capability names are what callers bind to.
| Fact | Direction | Consumed for | Staleness tolerance |
|---|---|---|---|
| Approved server and tool list | Registry → Gateway | Refusing unregistered capability outright | Minutes |
| Risk classification | Registry → Gateway | Selecting the policy set for a call | Minutes |
| Tool schema and version | Registry → Gateway | Validating arguments before execution | Minutes |
| Data classes touched | Registry → Gateway | Retention routing and step-up requirements | Hours |
| Owner and escalation path | Registry → Gateway | Approval routing and incident notification | Hours |
| Observed traffic per tool | Gateway → Registry | Detecting dead tools and real dependencies | Daily |
| Denial and approval statistics | Gateway → Registry | Reclassifying risk on evidence rather than assumption | Weekly |
In Barzel Central Gateway these are one product, which removes the integration work but does not remove the distinction — registry state and per-call policy remain separate concerns internally, because they change at different rates and are reviewed by different people.
Which to adopt first, in three situations
You cannot list your servers and owners
Registry first. Every policy decision you might write depends on facts you do not have. Spend four weeks on inventory, ownership and risk classification, and you will find that the act of classifying reveals two or three capabilities that should simply be removed.
Fast win: the ownership gate alone resolves most acute risk, because unowned servers are the ones nobody patches.
A specific dangerous capability is live and unguarded
Gateway first, narrowly. If an agent can issue refunds or delete records today, a per-call decision point on that one capability is worth more than a complete registry. Scope it to the dangerous tools and expand afterwards.
Fast win: one policy on one tool class, with human approval above a threshold, deployed in days.
Growing estate, several teams, audit pressure arriving
Both, registry leading by two weeks. Registry establishes the vocabulary — owners, classes, capability names — and the gateway then enforces against it. Doing them simultaneously usually means policy written against tool names, which you will rewrite.
Fast win: publishing risk classes early gives every subsequent policy conversation a shared language.
A pattern worth noticing across all three: the registry’s real product is not the list. It is the vocabulary. Once an organisation agrees what a capability is called and what risk class it belongs to, policy becomes a short document instead of an argument.
Next step
One product, two clearly separated concerns
Barzel Central Gateway carries the registry and the per-call decision point together, with registry facts feeding policy directly — so risk classes, owners and schemas cannot drift apart. Free tier includes both.
What neither component addresses
This comparison is about two governance components. Both share a boundary they cannot police.
- 01An agent holding a direct credential to an upstream system bypasses the registry and the gateway alike. Credential consolidation is upstream of both, and no amount of governance architecture substitutes for it.
- 02Neither component judges whether a capability should exist from a business perspective. They record and enforce a decision; the decision itself is human judgement.
- 03Neither prevents a correctly authorised action from being wrong. A refund the policy permits and the registry approved can still be fraud, which is why detection and reconciliation remain necessary.
Frequently asked questions
What is the difference between an MCP gateway and an MCP registry?
A registry is the authoritative catalogue of which servers and tools are approved to exist, with owners, schemas and risk classifications, decided by humans over days or weeks. A gateway is the decision point that authorises or refuses an individual tool call in milliseconds. The registry governs the existence of capability; the gateway governs its exercise.
Do I need both an MCP registry and an MCP gateway?
In almost any growing estate, yes. The registry supplies the facts — owner, risk class, schema, data classes — that gateway policy depends on, and the gateway enforces what the registry approved. Each alone has a characteristic failure mode: approved servers used in unapproved ways, or confident decisions about unreviewed capability.
Which should I implement first?
Registry first if you cannot currently list your servers and their owners, because every policy you might write depends on facts you do not yet have. Gateway first, scoped narrowly, if a specific dangerous capability such as refunds or record deletion is already live and unguarded.
Can a single product be both a registry and a gateway?
Yes, and several products are, including Barzel Central Gateway. The useful question is not whether they are one product but how registry changes propagate into policy decisions and how quickly — an approved-list revocation needs to take effect within minutes.
Is an MCP registry the same as a service catalogue?
Structurally similar and semantically different. An MCP registry must carry tool-level JSON Schemas, risk classifications, idempotency and reversibility attributes, and data-class annotations, none of which a general service catalogue has fields for.
What data flows from a registry to a gateway?
Five facts: the approved server and tool list, risk classification, tool schema and version, data classes touched, and owner with escalation path. The first three need to propagate within minutes because they are how a compromised capability is revoked.
What flows back from the gateway to the registry?
Observed traffic per tool, which reveals dead tools and real rather than declared dependencies, and denial and approval statistics, which allow risk classifications to be revised on evidence. A registry with no operational feedback becomes fiction within two quarters.
Why does a registry alone fail?
Because approving a server is not authorising its use. A CRM server approved for customer support can be used six months later by a marketing agent to bulk-export contacts, and every individual fact — approved server, approved tool, valid credential — is compliant.
Why does a gateway alone fail?
Two reasons. It renders confident decisions about capability nobody ever assessed for provenance, and without registry risk classes every policy rule must be written against tool names, so rule count grows linearly with tools and becomes unmaintainable.
What should the integration key between the two be?
A stable capability name rather than a hostname or URL. Hostnames and endpoints change during migrations; capability names are what callers bind to and what policy should be written against.
Does either component stop an agent with a direct credential?
No. An agent holding its own credential to an upstream system bypasses both, which makes credential consolidation a prerequisite rather than a later refinement. This is the most common reason a governance programme produces less risk reduction than expected.
How do registry and gateway together support change impact analysis?
The registry knows declared dependencies; the gateway knows observed traffic. Declared dependencies are always wrong in at least one direction, so the observed traffic is the correction. Neither alone can answer what breaks if a server is removed.
Glossary
- MCP registry
- The authoritative catalogue of approved MCP servers and tools, with owner, schema, risk class, data classes and lifecycle state.
- MCP gateway
- A component that mediates tool calls and renders a per-call decision, typically also handling identity, routing and evidence.
- Capability name
- A stable logical identifier for a capability that callers bind to and policy is written against, independent of which server provides it.
- Risk classification
- A registry-assigned category describing a tool’s consequence, reversibility and blast radius, consumed by policy.
- Deprecation lifecycle
- The registry-managed states a tool passes through from approved to withdrawn, with dates.
- Provenance assessment
- Registry-time evaluation of a third-party server’s origin, maintainer and integrity.
- Per-call authorisation
- A gateway decision about one specific invocation, using arguments and context unavailable at registry time.
- Staleness tolerance
- How long a fact may be out of date at the consuming component before the resulting decisions become unsafe.
- Declared dependency
- A registry-recorded relationship between components, as stated by their owners.
- Observed dependency
- A relationship inferred from actual traffic, which corrects the declared record.
Standards and entities referenced
Every named framework on this page resolves to a public definition. If you are checking our claims, start here rather than with us.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own operating judgement rather than something a standard states, the text says so.
- 01 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 02 · Center for Internet SecurityCIS Critical Security Controls ↗Control 1 and 2 — inventory of assets and software — restated here for MCP servers and tools.
- 03 · NISTNIST SP 800-207 — Zero Trust Architecture ↗The policy decision point / policy enforcement point split this architecture borrows directly.
- 04 · AxelosITIL 4 — change enablement ↗Established change-management vocabulary this article borrows for MCP estates.
- 05 · JSON SchemaJSON Schema Specification ↗How tool parameter contracts are expressed, and what a validator can enforce.
- 06 · SemVerSemantic Versioning 2.0.0 ↗The versioning contract tool schemas should honour but frequently do not.
- 07 · OpenSSFSLSA — Supply-chain Levels for Software Artifacts ↗Provenance and reproducibility framing for third-party server intake.
- 08 · ISOISO/IEC 42001 — AI management systems ↗The management-system standard auditors increasingly map AI governance evidence against.
Last reviewed 2 September 2026 by Mark Alex. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). MCP Gateway vs MCP Registry: Two Different Decisions. Real Biz Digital. https://realbizdigital.net/insights/mcp-gateway-vs-mcp-registry/
Try the mechanics on a live server
To watch a real tools/list response, and see how much surface one server exposes, 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 an evaluation costs an afternoon rather than a purchase order.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Community | Free | 1,000 tool calls/mo · full policy engine, registry, routing, audit | Evaluating the estate, or one team proving the path works |
| Starter | $10/mo | 10,000 calls/mo · everything in Community | One or two production agents against a handful of servers |
| Team | $79/mo | 100,000 calls/mo · routebooks, simulation, change impact | A platform team governing an estate of 5–20 servers |
| Business | $149/mo | 250,000 calls/mo · estate-wide evidence export | Multi-team governance with SIEM obligations |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
The five Barzel servers, and which problem each one is sold for
One estate rarely needs all five. This is the honest mapping, so you buy the layer your problem actually lives in.
| Server | Sold for | Entry price | Where it sits |
|---|---|---|---|
| Barzel Central Gateway | Knowing and governing the estate: inventory, registry, routing, risk scoring, approvals, evidence | Free, then $10–$149/mo | Control plane — decides what may be reached, and by whom |
| BarzelVault | Stopping a specific dangerous action before it executes, with proof afterwards | $199–$3,999/mo | Decision point — evaluates the individual call before execution |
| BarzelOps | Running real business workflows across HubSpot, Xero, Gmail, Drive and Slack under approval | Free, then $19–$199/mo | Execution layer — does the work the policy allowed |
| Barzel FinOps Atlas | Attributing AI spend to agents, tools and outcomes, then forecasting and capping it | Free, then $29–$799/mo | Economics layer — what the estate costs per outcome |
| Barzel Scripture Intelligence | A free, credential-free public MCP server to test clients and inspect real protocol traffic | Free, unmetered, no signup | Reference implementation — safe place to learn the protocol |
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.