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

A registry is a catalog that provides discovery, versioning, and curation, and it sits outside the request path. A gateway is a runtime proxy that fronts many servers behind one endpoint and sits in the request path, enforcing authentication, authorization, rate limits, and audit logging. Adopting a registry alone provides discovery and no control, which is a common and costly misunderstanding.

What does the stateless protocol core change in MCP?

The 2026-07-28 revision removes the initialize and initialized handshake, the Mcp-Session-Id header, and protocol-level sessions entirely, moving protocol version and client information into request metadata. The maintainers state that a remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer.

Is MCP an Anthropic project?

No. MCP is stewarded under the Linux Foundation through the Agentic AI Foundation, and the project site carries the 'a Series of LF Projects, LLC' notice. It is open for anyone to implement, which is why competing vendors ship first-class support rather than treating it as a rival's format.

MCP Servers for Development Environments

Model Context Protocol servers stopped being a desktop configuration detail and became shared infrastructure. This covers the difference between a registry and a gateway, how to self-host one, and why the protocol's move to a stateless core is fundamentally a horizontal scaling story.

From Local Config File to Platform Concern

What MCP is, who governs it, and why platform teams now own it

The Model Context Protocol is an open protocol for connecting AI applications to external data and tools. It uses JSON-RPC 2.0 between hosts, clients, and servers, and it defines what a server may offer - resources, prompts, and tools - along with client-side features such as sampling, roots, and elicitation. The specification itself draws the comparison to the Language Server Protocol: standardize the integration once and the whole ecosystem stops writing bespoke connectors.

Two things about its governance are worth stating plainly, because both are commonly got wrong. MCP is no longer an Anthropic-controlled project: it is stewarded under the Linux Foundation, through the Agentic AI Foundation, and the project's own site carries the "a Series of LF Projects, LLC" notice. And it is licensed for anyone to implement, which is why competing vendors ship first-class support rather than treating it as a rival's format.

The shift that matters for this site is where these servers run. The original mental model was a developer's machine launching MCP servers as local subprocesses from a JSON config file. That works for one person and fails as an organizational pattern, because every laptop ends up holding its own credentials for internal systems, with no central record of which tools are reachable or who used them. The CNCF's platform engineering guidance for AI-native workloads reflects the correction, listing "model serving, MCP gateways, and agentic guardrails" among the capabilities a platform is expected to provide natively, alongside policy-as-code enforcement and registry governance.

Local subprocess

The server runs as a child process of the client and speaks over stdio. Simple, no network exposure, and appropriate for anything that operates purely on the local workspace, such as filesystem access scoped to the checkout.

Remote server

The server is an HTTP service that many clients connect to. This is where shared internal systems belong, because the credential lives in the service rather than being copied onto every machine that wants access.

Behind a gateway

Clients connect to one internal endpoint that fronts many servers, applying authentication, authorization, and logging in one place. This is the pattern that scales past a handful of enthusiastic early adopters.

Registry, Gateway, Runtime: Three Different Things

A distinction worth getting right before you buy or build anything

These three terms are used loosely, including by vendors, and conflating them leads to procurement decisions that do not deliver what was expected. The short version: a registry tells you a server exists, a gateway sits in the request path and enforces rules, and a runtime is whatever actually executes the server process. Adopting a registry provides discovery and no control whatsoever, which is the mistake most worth avoiding.

Component	What it does	In the request path?	Solves
Registry	A catalog of available servers with metadata and install details	No	Discovery, versioning, curation of an approved list
Gateway	A runtime proxy fronting many servers behind one endpoint	Yes	Authentication, authorization, rate limits, audit, observability
Runtime	Whatever executes the server: a subprocess, container, or managed service	It is the endpoint	Isolation, resource limits, lifecycle, scaling

A registry entry is not a security review

Publication in any registry means a server was submitted, not that it was audited, and not that it is safe to point at your production database. If you maintain an internal catalog, the value comes from the review you perform before an entry is added, not from the catalog itself. The same caution applies to agent registries in the ACP ecosystem.

The Move to a Stateless Protocol Core

The change that turns MCP hosting into an ordinary scaling problem

The published specification revision is 2025-11-25. The next revision is dated 2026-07-28; it was locked as a release candidate on May 21, 2026, with beta SDKs published on June 29, 2026. Check the specification page for which revision is current when you read this, because the two are close together in the calendar.

The headline change in the 2026-07-28 revision is the elimination of the stateful core. The initialize and initialized handshake and the Mcp-Session-Id header are removed, along with protocol-level sessions entirely. Protocol version and client information move into request metadata instead. Under the previous design, a session pinned a client to one server instance, which is exactly the property that makes a service painful to operate at scale.

The maintainers' own framing

"A remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer, route traffic on an Mcp-Method header, and let clients cache tools/list responses for as long as the server's ttlMs permits."

Model Context Protocol blog, "The 2026-07-28 MCP Specification Release Candidate", May 21, 2026.

That is why this belongs on a site about development infrastructure rather than in a protocol changelog. Sticky sessions, a shared session store, and gateway-layer packet inspection are three separate pieces of operational machinery, each with its own failure modes, and the revision deletes the requirement for all of them. An MCP fleet stops being a special case and becomes an ordinary stateless HTTP service that any platform team already knows how to run, scale, and roll out.

The rest of the revision

A formal deprecation policy

Features move through Active, Deprecated, and Removed, with at least twelve months between deprecation and the earliest possible removal. For anyone deciding whether to build on the protocol, a published removal timeline is arguably worth more than any individual feature in the release.

Extensions become first class

An extensions framework adds formal identification, negotiation, and independent versioning, using reverse-DNS identifiers. This lets capabilities evolve on their own schedule instead of forcing everything through the core specification.

Tasks moves out of the core

Tasks graduates from an experimental core feature to an official extension, reshaped for stateless operation. Existing implementations need migration work, so if you have built on it, treat that as planned effort rather than an upgrade you can defer indefinitely.

Authorization hardening

Six protocol enhancement proposals tighten alignment with OAuth 2.0 and OpenID Connect. This matters most for remote servers fronting internal systems, which is precisely the deployment shape organizations are moving toward.

The honest caveat is that this is described by its own maintainers as the most substantial revision since launch, and it requires migration work. Servers, clients, and any gateway you operate all need to agree on a revision. If you are choosing a gateway now, the question to put to a vendor is not whether they support MCP but which specification revisions they support, and what their plan is for running mixed-version traffic during a transition.

Self-Hosting an MCP Gateway

What you get, what it costs, and what the client configuration looks like

From the client's perspective a gateway is unremarkable: one internal URL instead of a list of vendor endpoints and locally launched processes. That indirection is the entire point, because it means the set of reachable tools becomes a platform decision rather than the sum of what each developer happened to configure. A realistic mixed configuration keeps genuinely local, workspace-scoped servers as subprocesses and routes everything touching a shared system through the gateway.

// Client configuration: local server as a subprocess, shared
// systems routed through one internal gateway endpoint.
{
  "mcpServers": {
    "workspace-files": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem",
               "/workspace/payments-api"]
    },
    "issue-tracker": {
      "type": "http",
      "url": "https://mcp-gateway.internal.example/servers/issue-tracker"
    },
    "observability": {
      "type": "http",
      "url": "https://mcp-gateway.internal.example/servers/observability"
    }
  }
}

What a gateway buys you

One place to authenticate callers and authorize tool access
An audit trail of which tools were invoked, by whom, against what
Credentials held by the gateway rather than distributed to endpoints
Rate limiting and quotas on tools that hit expensive systems
Server changes roll out centrally, without touching every workspace

What it costs you

A new production dependency in the path of every agent action
A concentrated credential store, which is a high-value target
Version-skew management between clients, gateway, and servers
Ongoing curation work: someone must own the approved server list
Friction that pushes impatient developers back to local configs

That last cost is the one that quietly decides the outcome. A gateway only provides governance if it is the path of least resistance; if approving a new server takes weeks, developers will run it locally and the central record becomes fiction. Treat the approval workflow as part of the system you are designing, in the same way a good internal platform treats the paved path as a product rather than a mandate.

Credentials and the Security Surface

What the specification says implementors must handle themselves

The specification is candid that it cannot enforce its own security principles at the protocol level. It states that MCP "enables powerful capabilities through arbitrary data access and code execution paths," that tools "represent arbitrary code execution and must be treated with appropriate caution," and that tool descriptions and annotations "should be considered untrusted, unless obtained from a trusted server." Those are requirements handed to implementors, not guarantees the protocol provides.

Two categories of problem show up repeatedly in practice. The first is exposure: MCP servers reachable over the network with no authentication at all. Security researchers have reported scans finding these in significant and growing numbers through 2026; the specific counts vary by methodology and are worth treating as indicative rather than precise, but the class of problem is well established and the mitigation is not complicated. The second is the untrusted-content problem, where tool descriptions and returned data both enter the model's context and can carry instructions. A gateway helps materially with the first and only partially with the second.

Never distribute long-lived tokens

A static token copied into every workspace config cannot be scoped per user, is invisible in audit logs, and is unrevocable in practice. Terminate credentials at the gateway and issue short-lived, per-user tokens for the client hop.

Scope tools to least privilege

A server offering read access and one offering write access to the same system are different risk propositions. Split them, and grant the write variant deliberately rather than as a side effect of enabling the integration.

Log invocations, not just connections

Knowing a client connected tells you little. The useful record is which tool ran, with which arguments, on whose behalf, and what it returned - the same standard you would apply to any other privileged automation.

Pin server versions

A config that fetches the latest published package at launch means an upstream change reaches every workspace with no review. Pin versions and update them deliberately, as you would any other dependency in the supply chain.

Isolate the runtime

Third-party server code executing next to source and credentials deserves the same treatment as any untrusted workload. Container or microVM isolation with restricted egress is the appropriate default.

Keep a human in the loop for writes

The specification expects hosts to obtain explicit consent before invoking a tool. For irreversible actions, keep that approval rather than configuring it away for convenience during a pilot and then forgetting.

A Reasonable Sequence

Steps that hold regardless of which specification revision you land on

1. Inventory what is already running

Most organizations have MCP servers in use before anyone decides to adopt MCP, configured individually by developers. Find out which servers are configured, against which systems, with which credentials. This is usually the step that produces the surprises.

2. Separate local from shared

Servers that only touch the workspace can stay as local subprocesses indefinitely; they carry no shared credential and little central value. Anything reaching an internal system is the candidate for centralization. Do not migrate everything on principle.

3. Route shared servers through one endpoint

Start with the two or three servers that matter most rather than a complete platform. Verify that authentication, authorization, and invocation logging genuinely work end to end before expanding the catalog.

4. Plan for the revision boundary

Record which specification revision each client, gateway, and server speaks, and confirm your gateway's position on running mixed versions. If you use Tasks, budget the migration to the extension form explicitly.

5. Design the approval path as a product

Decide who reviews a new server, against what criteria, and how long it should take. A governance process nobody can navigate produces shadow configuration, which is strictly worse than the decentralized state you started from.