MCP Gateway

The MCP Gateway is the governed place where an organization connects its MCP servers and delivers them, along with skills and plugins, to the people and agents that use them.

The gateway sits between AI agents, such as Claude Code, Cursor, or a custom agent, and the MCP servers they call. Instead of configuring each server in each agent, agents can connect through one URL that fronts many servers. On every request, the gateway authenticates the caller and checks their access to the server and tool. Access follows the organization’s identity provider. Directory sync provisions members and maps directory groups to roles. Every tool call has guardrails applied, and a record created specifying the call, the agent and the associated person behind it.

On developer machines, the device agent keeps those tools pointed at the gateway. It writes the organization’s assigned plugins and MCP servers into the native configuration of each AI tool, such as Claude Code, Cursor, and Codex, and re-applies them every 60 seconds by default, so the configuration survives tool updates and account switches. Gateway controls apply only to traffic that routes through the gateway, and the device agent makes sure it does. See Device agent.

The MCP Gateway is free to start. The quickstart connects a first server to Claude Code in five steps, and Pricing covers plans as usage grows.

Explore the platform

How the gateway works

When each MCP server is configured in each agent, the agent harness decides which tools people have, and changing that means updating every client. The gateway moves tool management out of the harness and into one centralized system, where administrators add, remove, and restrict servers and tools in one place.

The Speakeasy gateway serves the same five tools regardless of the number of MCP servers contained in the gateway:

list_servers returns the reachable servers, what each one is for, and each server’s status. The gateway is identity-aware, so agents only see servers they can access.
describe_server returns a specified server’s tools with descriptions.
describe_tools returns the input schemas and descriptions for the specific tools the agent intends to call.
execute_tool runs the specified tool, and returns the tool’s payload upon completion.
connection_status shows the status of connection between the agent and server.

Because the agent’s own tool list never changes, servers and tools added, removed, or restricted on the gateway take effect the next time the agent lists servers or describes tools, with no change to the client configuration.

The gateway’s built-in instructions teach agents how to use the gateway server: to work from the outside in, never to execute a tool they have not described (guessed arguments fail validation), and to re-check list_servers before retrying a failed call.

Connecting MCP servers to a gateway

An organization’s MCP servers come in many different flavors. Teams use vendor MCP servers, like Linear and Slack, and also build servers for internal systems. Internal servers may be public or run on a private network.

Whatever their type and however they are exposed, they can all be connected to the Speakeasy gateway. Every server sits behind the same sign-in, access rules, and logging.

MCP 2026-07-28 supported

The gateway supports MCP protocol version 2026-07-28. Clients and upstream servers on an older protocol version keep working: the gateway falls back to the version each side supports, so nothing has to upgrade in step.

Server type	What it is	Start here
Remote	A server someone else runs, such as a vendor’s MCP server. Add it by URL or from the catalog.	Remote MCP servers
Tunneled	A server that runs inside a private network, behind a firewall or in a VPC. It connects without opening the network to inbound traffic.	Tunneled MCP servers
Hosted	An API that has no MCP server yet. Speakeasy generates the server from an OpenAPI document or TypeScript functions and runs it.	Building MCP servers

Connecting agents to a gateway

Instead of connecting each MCP server to an agent individually, add the gateway URL as the agent’s only MCP server. That one URL is all the agent needs. Servers added to the gateway later become available to the agent with no changes on the user’s side.

The gateway works with the following agent platforms. For setup steps per client, see Integrations.

Platform	Status
	Supported
	Supported
Cursor	Supported
GitHub Copilot	Supported
OpenCode	Supported
Azure AI Foundry	Supported
OpenClaw	Supported
Hermes	Supported
Grok Bot	Supported
Muse	Supported
Gemini	Supported
Glean	Supported
Mistral	Supported
	Supported
Custom Agents	Supported

In this section

Add servers

Remote MCP servers: register a server someone else runs, by URL.
Tunneled MCP servers: give a server inside a private network a URL through an outbound tunnel.
MCP Catalog: add reviewed third-party servers from the official MCP Registry.
Building MCP servers: generate a hosted server from an OpenAPI document or TypeScript functions.

Combine and deliver

Gateway Endpoints: put several servers behind one address, one sign-in, and one consent screen.
Organization gateway: one URL that reaches every server a person has access to, across all projects.
Plugins: bundle servers and skills, assign them to roles, and publish them to agent marketplaces.
Skills: record, version, and measure the skills agents load.
Assistants: deploy governed assistants to Slack.

Configure and secure

Managing an MCP server: visibility, addresses, team access, guardrails, sessions, and monitoring for one server.
Environments: shared configuration and secrets, kept out of client configuration.
Private Network Access: serve servers and gateway endpoints through private Tailscale URLs.
Tool discovery: how each server type gets its tool list, and which tool features apply.
Access, OAuth, and sessions: who is calling a server, which credential it uses upstream, and who may connect.
Roles and Permissions: the mcp:read, mcp:write, and mcp:connect scopes that decide who can view, manage, and connect to servers.