Bring your own gateway. Keep the controls you built.
Point the runtime at the gateway your team already operates. Your allowlist, your identity, your audit trail, with composition and per-workspace scoping added on top.
Your gateway is just a remote connection.
A gateway that speaks MCP is reachable the way any remote server is: Streamable HTTP or SSE, with OAuth discovery over the published standards. There is no adapter to write and no certification programme to join, because the protocol is the integration.
- Streamable HTTP or SSE Whichever transport your gateway exposes. Both are first-class here.
- Standards for auth OAuth discovery over RFC 9728 and RFC 8414, so your identity provider stays yours.
- Direct also works No gateway is required. Point at a server you trust and hold the auth yourself.
You keep the layer you already got signed off.
The runtime is a consumer of your gateway, not a replacement for it. Whatever it enforces still gets enforced, because every call the agent makes arrives as an ordinary MCP request from an ordinary client.
- No second allowlist Vendor policy stays in one place, and it stays in the place you audit.
- No credential copy The gateway holds what it holds. We never need a copy to route around it.
- Two records, not a gap Your gateway logs the call. We attribute it to a person and a workspace.
It is an MCP server as well as a client.
The runtime exposes its own MCP endpoint, so the hosts your team already uses can consume the composed toolset. Your gateway feeds the runtime; the runtime feeds Claude Code, Claude Desktop or Cursor, with the scoping intact.
- One endpoint out Streamable HTTP at /mcp, with OAuth discovery for automatic client setup.
- Composed, then scoped Local servers, remote servers and your gateway arrive as one toolset.
- Same wall either way A session gets one workspace, whichever client opened it.
Where you are starting from
Three ways teams arrive at this page.
The answer differs, and only one of them involves changing what you run.
Keep it. Point the runtime at it.
Your allowlist, identity integration and audit trail were work, and none of it is wasted. The runtime connects as one more client and inherits everything the gateway enforces, so the review your security team already did still holds.
How isolation worksNothing to migrate
The gateway keeps its vendors, its credentials and its policy.
Nothing to re-review
The runtime cannot reach past what the gateway already allows.
You gain scoping
Per workspace and per task, which a gateway does not model.
Decide it on its own merits.
A gateway solves discovery and authorization across many remote servers. That is worth having at a certain number of vendors and is overhead below it. Nothing here pushes the decision either way, because the runtime works with one and without one.
See the connectorsWorth it above a threshold
When authorising each remote server yourself becomes the bottleneck.
Not a dependency here
Adopt one later and the runtime configuration is a connection change.
No lock-in either way
It is a published protocol on both sides of the connection.
You do not need one.
Connect directly to servers you trust and hold the authorization yourself, or install from the built-in directory. A gateway is a convenience over the protocol rather than the thing that makes the protocol work.
Browse the registryDirect connections
Point the runtime at an endpoint and hold the credential yourself.
The built-in directory
Installable in a click, with no third party in the path at all.
Servers you write
Reachable on the same terms as anything you did not write.
MCP gateways
Questions people ask about gateways
Do we have to replace the gateway we already run?
Which gateways do you support?
What does the runtime add that our gateway does not?
Do you need a copy of our credentials?
Can our existing MCP clients use this?
What happens when a downstream account expires?
Do we need a gateway at all?
More of the platform
Each capability has a page. These are the ones nearest this.