Based on the current stable MCP specification

Gateway & governance

Govern the MCP estate without turning the gateway into the protocol.

An MCP gateway can provide a controlled route to approved servers, but it is not an MCP host, client, server or core primitive. Enterprise governance also needs a private registry, named owners, versioned capability records and evidence for every material change. This page separates those responsibilities so routing infrastructure does not become an undocumented source of policy or truth.

Technical guide by David Máj, Founder & Technology Consultant.

TechOne architecture position

Use three distinct control points: runtime routing, catalogue governance and server enforcement.

The gateway handles traffic at the enterprise boundary. The private registry records which servers and releases are approved. Each MCP server remains responsible for its protocol behaviour, tool and resource contracts, input validation, authorisation decisions and downstream controls.

Keeping those roles separate prevents a routing tier from silently becoming the capability catalogue, identity authority and business-policy engine. It also makes ownership, failure isolation, change review and retirement visible to management, security and operations.

MCP 2026-07-28 is stateless at the protocol layer. Streamable HTTP requests carry routing metadata that infrastructure can inspect without parsing the JSON-RPC body, while the body remains the source of truth. Governance should use that property without inventing a gateway-specific dialect of MCP.

Illustrative reference architecture

A gateway earns its place by enforcing a shared rule.

It is not required by MCP. Introduce one when multiple hosts or servers need common routing, policy, inventory or telemetry—and keep business authorisation in the system that owns the decision.

MCP gateway architecture nodes

01
Core MCP participant
MCP host
The AI application that coordinates one or more MCP clients and decides how discovered capabilities are made available to the model and user.
The host owns user experience, model context, consent and confirmation behaviour. The gateway must not infer user intent on the host’s behalf.
02
Core MCP participant
MCP client
The host-side component that communicates with one MCP server, sends version and capability metadata and calls server primitives.
Client identity metadata is useful for display, logging and compatibility, but it is not an authentication credential or an authorisation decision.
03
Enterprise infrastructure component, not a core MCP primitive
MCP gateway
A controlled ingress and routing tier for approved remote MCP traffic, with policy enforcement, metering, rate limits, trace propagation and operational isolation where the architecture requires them.
A gateway does not become an MCP server merely because it forwards MCP requests. If it aggregates or rewrites capabilities and presents them as its own endpoint, that behaviour must be designed, tested and governed as an MCP server or protocol-aware intermediary in its own right.
04
Enterprise governance component, not a runtime MCP primitive
Private MCP registry or catalogue
The approved inventory of servers, releases, owners, endpoints, transports, protocol support, authentication profiles, capability fingerprints and lifecycle states.
The registry describes what the organisation has approved. It does not execute tools, proxy traffic or replace live protocol discovery. A live server response remains authoritative for what that endpoint currently exposes, subject to enterprise policy.
05
Core MCP participant
MCP server
The programme that exposes tools, resources or prompts to MCP clients and implements the protocol contract for its endpoint.
The server validates inputs, checks access, applies business rules, calls downstream systems, sanitises outputs and returns protocol-correct results. These duties cannot be delegated to a catalogue entry.
06
Enterprise security dependency
Identity and policy services
Authenticate principals, issue or validate audience-bound credentials, resolve scopes and attributes, and supply policy decisions where required.
The gateway may enforce a policy decision, but the MCP server must still validate credentials and permissions applicable to its protected resource. Token passthrough is not an acceptable shortcut.
07
System of record or operational dependency
Downstream system
The API, database, document store or business service that the MCP server reads or changes.
Its native permissions, data rules and transaction controls remain in force. MCP does not supersede the downstream system’s security or integrity model.
08
Enterprise operations dependency
Observability and evidence store
Correlate requests across host, gateway, server and downstream services and preserve approved operational evidence without recording secrets unnecessarily.
Telemetry is evidence of what infrastructure observed, not proof that a business outcome was correct. Logs require access control, retention and redaction rules of their own.

Illustrative topology. A direct host-to-server connection remains valid when central mediation adds no useful control.

Do not collapse the planes

Discovery, policy, execution and evidence have different owners.

Data plane

Carries live MCP requests and responses between clients and approved servers.

For Streamable HTTP under MCP 2026-07-28, infrastructure can route and meter using MCP-Protocol-Version, Mcp-Method and, where defined, Mcp-Name. The JSON-RPC body remains the source of truth, and the receiving server must reject a header/body mismatch.

Request identifier, authenticated principal, target server, Mcp-Method, Mcp-Name where present, decision, latency, response class and trace correlation — with sensitive arguments and credentials excluded or redacted.

Control plane

Applies enterprise decisions about which principals, hosts, servers and named capabilities may communicate.

Identity, audience, scope, server state, risk class and environment are evaluated before routing or execution. A gateway denial does not remove the server’s duty to authorise and validate the request.

Policy version, matched rule, decision, reason, approver where required and the exact capability identity evaluated.

Governance plane

Maintains the approved catalogue, ownership, schema evidence, lifecycle state and change decisions.

A release is assessed against the registry record, schema fingerprints, privileges, tests and operational evidence before its state changes. The governance plane does not sit in the protocol request path by necessity.

Approved registry record, review decision, test report, risk acceptance where applicable, effective date, replacement path and retirement evidence.

Gateway boundary

Centralise cross-cutting controls, not hidden authority.

The gateway can own

Route without inventing protocol semanticsRoute Streamable HTTP requests using the standard MCP-Protocol-Version and Mcp-Method headers, plus Mcp-Name where the protocol mirrors a named tool, prompt, resource or task identifier. Preserve the body unchanged unless the gateway is explicitly designed and tested as a protocol-aware intermediary.
Restrict destinations to approved server recordsResolve routes from a controlled configuration linked to active private-registry records. Do not allow request-supplied hosts, arbitrary redirects or unreviewed discovery metadata to become routing destinations.
Enforce transport and edge policyTerminate or pass through TLS according to the trust model, validate the intended audience at the protected-resource boundary, apply request-size and rate limits, and reject unsupported protocol versions or destinations before they consume downstream capacity.
Apply capability-aware policy where evidence existsUse Mcp-Method and Mcp-Name for routing, metering and coarse policy only when the header is present for that method. Do not infer arguments, business intent or safety from a tool name. The MCP server remains responsible for validating the body and enforcing operation-level rules.
Preserve identity and credential boundariesForward only credentials intended for the target MCP protected resource. Never pass an inbound token through to a downstream API. Downstream access uses a separate credential flow owned by the MCP server or an approved identity broker.
Propagate trace context and record decisionsKeep correlation across the host, gateway, MCP server and downstream call. Record routing and policy decisions without logging bearer tokens, cookies, secrets or unrestricted tool arguments.
Fail closed on ambiguous routesReject unknown servers, inactive catalogue records, unsupported versions, malformed routing metadata and policy failures. Do not silently fall back to a broader server or a less restrictive route.
Isolate availability failuresUse bounded timeouts, connection limits, circuit controls and health information so one slow or failing MCP server does not exhaust the shared ingress tier.

The gateway cannot prove

A gateway is not a core MCP primitiveThe core participants are hosts, clients and servers. Gateway behaviour belongs to the enterprise deployment architecture and must not be presented as a protocol guarantee.
A gateway is not the private registryRuntime routing configuration may be generated from approved registry records, but a route table is not a complete ownership, version, evidence or retirement record.
A gateway is not the MCP serverIt cannot replace server-side input validation, resource URI checks, tool access controls, downstream authorisation, output sanitisation or business integrity rules.
Headers do not prove that a call is safeMcp-Method and Mcp-Name expose routable metadata. They do not describe all arguments, affected records, user intent or operational impact.
A catalogue approval is not perpetual trustAn approved record can become stale as schemas, dependencies, credentials, ownership or risk change. Live enforcement and periodic review remain necessary.
A gateway cannot make token passthrough validTokens must be issued for and validated by the intended MCP resource. The server must use separate credentials when it calls downstream APIs.
Aggregation creates a new responsibility boundaryIf a gateway merges tool lists, rewrites names, translates schemas or returns results as one MCP endpoint, it is performing server-like behaviour that requires its own contracts, versioning, conformance tests and ownership.

Topology decision

Direct connection or governed gateway?

Option	Use when	Required controls	Trade-off
Direct client-to-server connection	One approved host connects to a small number of servers within an existing trust boundary, and identity, network, rate limiting and audit controls already exist at the endpoints.	Pinned endpoint, audience-bound authorisation, server-side access control, tested schemas, direct telemetry and an approved registry record.	Fewer shared components and failure modes, but policy, discovery and evidence can fragment as the number of hosts and servers grows.
Shared MCP gateway	Multiple hosts or business units require consistent ingress, destination control, metering, trace correlation and coarse capability policy across many remote servers.	High availability, route ownership, active-registry integration, fail-closed policy, credential separation, privacy-aware logging and a tested bypass prohibition.	Consistent control and visibility, but the gateway becomes critical infrastructure and may create a large blast radius if policy or routing is wrong.
Domain gateways or segmented ingress	Risk, residency, ownership or availability requirements differ materially between domains such as finance, operations and public information.	Common registry model and evidence standard, with separate route sets, owners, credentials and failure domains.	Better isolation and accountability, with more platform components to operate and keep consistent.
Aggregating MCP endpoint	The enterprise deliberately wants to expose a curated virtual capability surface rather than route transparently to independent servers.	Explicit server ownership, name-collision policy, schema translation rules, provenance in results, version compatibility, conformance tests and retirement behaviour.	Simpler client configuration, but aggregation changes contracts and must be governed as more than a network proxy.

Private catalogue

The private registry is an approved catalogue, not a runtime substitute for protocol discovery.

Keep self-reported server metadata, enterprise approval and live capability evidence distinct. A registry record may import public MCP Registry data, but internal approval, ownership and environment-specific controls are separate enterprise decisions.

Record IDStable enterprise identifier independent of display name or deployment URL.
Server identity and ownerApproved server name, accountable business owner, technical owner, support team and escalation route.
Canonical server URIThe exact protected-resource identifier and approved endpoint or endpoints per environment.
Source and provenanceInternal build, approved supplier or imported public-registry record, with repository, package or artefact reference where applicable.
Release versionThe deployable server release governed by the record; never infer compatibility from a moving latest tag.
Protocol supportSupported MCP revisions, required extensions and any documented legacy compatibility.
Transport profilestdio, Streamable HTTP or an explicitly reviewed custom transport, including endpoint and network boundary.
Authorisation profileProtected-resource metadata, issuer, accepted audiences, scope model, client types and downstream credential boundary. No secrets belong in the record.
Capability inventoryApproved tools, resources and prompts, including names, risk class, owning system and expected human decision points.
Schema fingerprintEnterprise governance hash over the canonicalised capability contract — including name, input schema and output schema where present — used to detect an unreviewed contract change. This is a TechOne governance control, not an MCP protocol field.
Schema evidenceThe canonical contract artefact, fingerprint algorithm and normalisation rules required to reproduce the recorded fingerprint.
Data classificationThe highest data class each capability may access or return, with residency and retention constraints.
Operational profileTimeouts, rate limits, dependencies, service objective, telemetry destination and runbook.
Lifecycle stateProposed, assessed, approved, active, restricted, deprecated, retired or rejected, with effective date and decision owner.
Replacement and retirementSuccessor record, migration deadline, client notification plan, credential revocation and evidence-retention requirements.
Review evidenceArchitecture, security, privacy, conformance, acceptance and operational review references appropriate to the risk.

Schema change ruleA changed fingerprint opens a review; it does not by itself determine whether the change is compatible. Review must classify additions, removals, renamed capabilities, schema constraint changes, changed descriptions that alter model selection, and any increase in data or action scope.

Runtime ruleCompare the approved record with deployment evidence and live discovery at release time and on a defined review cadence. If the active endpoint exposes an unknown capability or incompatible schema, restrict or withdraw the route until the difference is understood.

Capability lifecycle

Approval is a state, not a one-off meeting.

01
Proposed
An owner has submitted a server or release record, but no enterprise use is authorised.
Allowed: Design review, isolated development and non-sensitive conformance testing.Exit evidence: Named owners, architecture, capability inventory, initial schemas, data classification and intended consumers.
02
Assessed
Architecture, security, data and operational reviews are complete enough for a decision.
Allowed: Controlled pre-production tests with the approved identities, data and environment.Exit evidence: Resolved findings, test results, authorisation profile, schema fingerprints, runbook and rollback plan.
03
Approved
The release and its declared capability surface are approved for a named environment and consumer set.
Allowed: Deployment preparation and route activation under the approved conditions.Exit evidence: Change decision, deployment artefact identity, effective date and accountable approver.
04
Active
The approved endpoint is available through its authorised route and is under operational monitoring.
Allowed: Only the recorded versions, capabilities, principals, environments and policy conditions.Exit evidence: Operational review, material change request, restriction decision, deprecation decision or retirement completion.
05
Restricted
Use is temporarily narrowed because of an incident, control gap, ownership issue or unreviewed change.
Allowed: Explicitly named read-only capabilities, principals or diagnostic traffic only; everything else is denied.Exit evidence: Remediation evidence and re-approval, or a decision to deprecate or retire.
06
Deprecated
Existing approved consumers have a time-limited migration window; new consumers are not admitted.
Allowed: Existing recorded use until the retirement deadline, with heightened change restrictions.Exit evidence: Consumer migration, replacement validation, support closure and confirmed retirement date.
07
Retired
The route, credentials and deployment are disabled and the record is retained for evidence.
Allowed: No production calls.Exit evidence: Route removal, credential revocation, endpoint shutdown, consumer confirmation and retained audit references.
08
Rejected
The proposal was not approved or cannot meet the required controls.
Allowed: No enterprise deployment or route.Exit evidence: A new proposal must address the recorded decision; rejection is not silently overwritten.

Named accountability

Every capability needs an owner, an operator and evidence.

Role	Responsibility	Evidence
Business capability owner	Defines the legitimate outcome, eligible users, unacceptable actions, human decision points and measures of value.	Approved purpose, capability scope, risk classification, user population and acceptance scenarios.
MCP server owner	Owns protocol conformance, capability contracts, validation, server-side access control, downstream calls, output handling, releases and support.	Versioned code or artefact, schemas, tests, dependency record, runbook, release notes and incident ownership.
Gateway or platform owner	Owns ingress availability, route configuration, edge policy, metering, trace propagation, isolation and recovery of the shared tier.	Route-as-code, policy tests, capacity evidence, dashboard, alerting, recovery test and approved change history.
Private registry custodian	Maintains the record model, approval state, provenance, schema evidence, ownership completeness and retirement history.	Immutable decision history, validation rules, stale-record reports and reconciliation with active routes and deployments.
Identity and security owner	Approves issuer, audience, scopes, client registration, credential storage, network controls, token separation and security monitoring.	Threat model, authorisation tests, protected-resource metadata, issuer configuration, policy decisions and incident procedures.
Downstream system owner	Approves the native API operations, data access, service identity, transaction behaviour, limits and support impact exposed through the MCP server.	API contract, permission grant, test tenant evidence, limits, change notice route and revocation procedure.
Operations or SRE owner	Monitors availability and performance, responds to incidents, validates rollback and confirms that telemetry is sufficient without exposing secrets.	Service objectives, dashboards, alerts, on-call route, rollback exercise, post-incident record and capacity review.
Risk, privacy and legal reviewers	Review the specific data, user, supplier and regulatory implications assigned by internal policy; they do not approve protocol conformance by proxy.	Scoped findings, conditions, expiry or review date and accountable internal approval where required.

Changes that require an explicit gate

Change	Trigger	Checks	Evidence
New server or first enterprise route	A previously unapproved MCP endpoint, supplier, package or internal server is proposed.	Ownership, provenance, protocol support, transport, authentication, capability inventory, data classes, schema fingerprints, downstream permissions, failure tests, telemetry and retirement path.	Approved registry record, architecture and threat model, conformance and acceptance results, runbook and route-as-code change.
Additive capability or schema change	A tool, resource or prompt is added, or an optional field or enum value expands the contract.	New privilege, model-selection effect, name collision, compatibility, data exposure, rate impact, client caching and updated tests.	New fingerprint, contract diff, classification decision, acceptance tests and approved release record.
Breaking contract change	A capability is removed or renamed, a required field changes, constraints narrow, output shape changes or behaviour is no longer compatible.	Affected consumers, parallel versioning, migration window, route or name strategy, rollback and retirement of the former contract.	Consumer inventory, migration plan, dual-run or compatibility test, effective date and deprecation notice.
Privilege or impact increase	Read becomes write, write becomes destructive, accessible records expand, approval is removed or a broader downstream identity is introduced.	Business necessity, least privilege, scopes, human approval, separation of duties, rollback, transaction controls and incident containment.	Fresh security and business approval, negative tests, exact permission diff and updated risk record.
Authorisation or identity change	Issuer, audience, client registration, scopes, token handling or downstream credential flow changes.	Protected-resource metadata, issuer and audience validation, step-up behaviour, token separation, revocation and affected clients.	Authorisation-flow test, configuration review, secret-rotation evidence and rollback plan.
Endpoint, transport or gateway route change	Canonical URI, environment endpoint, transport, gateway, region or route policy changes.	Resource indicator, TLS, DNS and redirect behaviour, allowlists, latency, availability, cancellation, header/body validation and telemetry continuity.	Route diff, connectivity and failure tests, updated registry record and post-change verification.
Protocol baseline or extension change	The server adds or removes a supported MCP revision or optional extension.	Client compatibility, fallback behaviour, deprecated features, schema and error changes, conformance suite and operational rollback.	Compatibility matrix, conformance results, client validation and approved release notes.
Deprecation and retirement	A server, release or capability is no longer strategic, supported, compliant or safe.	Consumer inventory, successor, migration deadline, route closure, credential revocation, endpoint shutdown and evidence retention.	Deprecation decision, consumer acknowledgements, completed migration, disabled route and retained retirement record.
Emergency restriction	An incident, vulnerability, ownership loss or unexplained schema difference creates immediate risk.	Minimum safe capability set, affected principals, containment route, communication, evidence preservation and restoration criteria.	Incident decision, temporary policy, active restriction verification and time-bound remediation owner.

Primary sources

Checked against the stated protocol baseline.

Official sources establish the protocol baseline and identify any draft extension. Unless a statement is labelled as a protocol fact, the surrounding control pattern is a TechOne architecture recommendation.

MCP 2026-07-28 specificationNormative protocol baseline and links to core protocol, server features, transports, authorisation and versioning.
MCP architecture overviewHost, client and server roles; data and transport layers; tools, resources and prompts as protocol primitives.
MCP transport overviewTransport responsibilities, Streamable HTTP, per-request metadata, mirrored HTTP routing metadata and the body as source of truth.
MCP 2026-07-28 releaseStateless protocol operation and the Mcp-Method and Mcp-Name routing headers for Streamable HTTP.
MCP authorisation specificationProtected-resource roles, resource indicators, audience validation, scope guidance and the prohibition on accepting or transiting tokens intended for other resources.
MCP security best practicesConfused-deputy, token-passthrough, SSRF, state-handle, local-server and authorisation security considerations.
MCP versioning and compatibilityPer-request protocol versioning, server discovery, extension negotiation and compatibility with earlier handshake-based revisions.
Official MCP Registry referenceThe official public registry API and server metadata model.
Introducing the MCP RegistryThe distinction between the public MCP Registry and public or private sub-registries built for organisation-specific criteria.

Direct answers

Questions that expose the hidden architecture decision.

Is an MCP gateway part of the MCP core protocol?

No. MCP defines hosts, clients and servers, together with protocol primitives such as tools, resources and prompts. A gateway is an enterprise deployment component that can route, meter and enforce edge policy for remote MCP traffic. Its behaviour and controls must be specified by the organisation operating it.

What is the difference between an MCP gateway and an MCP server?

An MCP server exposes protocol capabilities and owns their contracts, validation, access control and downstream behaviour. A transparent gateway routes requests to approved servers and applies shared infrastructure controls. If a gateway merges, renames or rewrites capabilities and serves them from its own MCP endpoint, it has taken on server-like responsibilities that require separate governance and testing.

What is the difference between a gateway and a private MCP registry?

The gateway is in the runtime request path. The private registry is the approved catalogue of servers, versions, owners, endpoints, capability evidence and lifecycle states. Registry approval can configure or constrain routes, but the registry does not execute tools and a gateway route table is not a complete governance record.

Can a gateway route MCP calls without parsing the JSON-RPC body?

For Streamable HTTP in MCP 2026-07-28, infrastructure can route and meter requests using MCP-Protocol-Version, Mcp-Method and Mcp-Name where defined. The body remains the source of truth, and the MCP server must reject a request when mirrored headers and body disagree. Headers expose routing metadata, not the full business meaning or safety of a call.

Is schema fingerprinting required by MCP?

No. Schema fingerprinting is an enterprise governance control proposed here to detect changes in approved capability contracts. The organisation must define canonicalisation and hashing rules, retain the source schema and review the semantic change; a fingerprint alone does not establish compatibility or safety.

Should the private registry replace live MCP discovery?

No. The registry records what the enterprise approved, while live discovery reports what an endpoint currently exposes. Release and periodic controls should compare the two. An unexplained capability or schema difference should restrict the route until it is reviewed.

When is a direct MCP connection preferable to a gateway?

A direct connection can be preferable when one approved host connects to a small number of servers inside an existing trust boundary and endpoint controls already provide identity, authorisation, limits and audit evidence. A gateway becomes more useful when many hosts and servers need consistent destination control, metering, trace correlation and operational isolation.

Can the gateway forward a user token to the downstream business API?

No. The MCP server must accept only tokens intended for its protected resource, and token passthrough to a downstream API is forbidden. Downstream access requires a separate credential or delegated flow designed for that API and governed by the server and identity architecture.

What must happen when a server is retired?

Stop new consumers, identify and migrate existing ones, remove the active route, revoke credentials, shut down the endpoint, close support ownership and retain the registry decision and required audit evidence. Deleting a catalogue entry alone does not retire a deployed server.

Commercial route

Turn the architecture question into a controlled next step.

We begin with the system boundary, intended capabilities, identities and consequences—not with a gateway product or SDK preference.

Assess MCP readiness Explore the complete MCP architecture

Govern the MCP estate without turning the gateway into the protocol.

A gateway earns its place by enforcing a shared rule.

MCP gateway architecture nodes

MCP host

MCP client

MCP gateway

Private MCP registry or catalogue

MCP server

Identity and policy services

Downstream system

Observability and evidence store

Discovery, policy, execution and evidence have different owners.

Data plane

Control plane

Governance plane

Centralise cross-cutting controls, not hidden authority.

The gateway can own

The gateway cannot prove

Direct connection or governed gateway?

The private registry is an approved catalogue, not a runtime substitute for protocol discovery.

Approval is a state, not a one-off meeting.

Proposed

Assessed

Approved

Active

Restricted

Deprecated

Retired

Rejected

Every capability needs an owner, an operator and evidence.

Changes that require an explicit gate

Checked against the stated protocol baseline.

The neighbouring decisions matter.

Questions that expose the hidden architecture decision.

Turn the architecture question into a controlled next step.