Choose an MCP gateway URL
Pick the gateway URL an agent connects to, from every tool in one list down to one server or a labeled set
An agent that connects to every MCP server at once can hit its tool-count cap, and every tool in its list costs context on each request. The gateway gives every agent the URL that matches the tools it needs, from all of them down to a handful.
Scoped gateways
A scoped gateway is a gateway URL narrowed to part of your MCP servers and tools. You don't deploy or configure anything to get one: you change the URL the agent connects to, and the gateway serves the narrower tool list.
Aggregated URL /gateway/mcp every server and tool
Scoped gateways
├ Per-server MCP /gateway/mcp/{slug} one server
├ Per-service MCP /gateway/mcp/{slug}?upstreams=… chosen services within one server
└ Virtual MCP /gateway/mcp?tags=… a labeled set, across serversScoped gateways help when:
- An agent caps its tools. Some agents refuse to connect, or drop tools, past a fixed number.
- Context is tight. An agent reads every tool definition in its list on each request, so a shorter list leaves more room for the work.
- Different agents do different jobs. A support agent and a coding agent can share one gateway and each see only the tools for its job.
Every scoped gateway is the same gateway behind a different URL. The same rules, data protection, usage limits and Agent Trail apply, whichever URL an agent uses.
Each URL starts with https://<your-gateway-url>.
Aggregated URL
/gateway/mcp puts every tool your rules allow the person into one list, from every MCP server your organization added.
Add a server later and the agent picks up its tools with no change to the agent.
Start here unless the agent caps how many tools it accepts.
Per-server MCP
A per-server MCP is one MCP server on its own: /gateway/mcp/{slug}, such as /gateway/mcp/github.
The agent sees only that server's tools, as if it had connected to the server directly, but every call still goes through your rules.
The slug is the catalog name for a catalog server, or the slug you set when you add a custom server.
An unknown slug returns 404.
Use it for an agent that works in one service, such as a coding agent that only needs GitHub.
Per-service MCP
A per-service MCP is part of one server.
Some catalog servers bundle several services behind one server, such as Microsoft 365 Work IQ (Mail, Calendar, Teams, SharePoint) or Google Workspace (Gmail, Drive and more).
Add ?upstreams= to a per-server URL and pick one or more of its services, such as /gateway/mcp/googleworkspace?upstreams=gmail,drive.
The services always belong to the one server in the URL, so ?upstreams= can't reach across servers.
An unknown service returns 404.
The connect dialog lists a server's services in its Upstreams picker.
Use it for an agent that needs one or two services of a large bundle, such as a scheduling agent that only needs Calendar.
Virtual MCP
A virtual MCP is a server that doesn't exist on its own:
the gateway assembles it from the labels you choose, across every server.
Add ?tags=, such as /gateway/mcp?tags=dev,read-only.
- A tool is included when its server carries a listed label, or when the tool itself does.
- Several labels combine: a tool needs only one of them.
- Built-in labels work too:
?tags=read-onlygives the agent only read-only tools, across every server. - A label that doesn't exist returns
404, and one that labels nothing gives an empty tool list.
To connect an agent to several servers, label them and use a virtual MCP.
Label GitHub, Linear and Sentry dev, and /gateway/mcp?tags=dev gives the agent all three.
Label a fourth server dev later, and every agent on that URL gets its tools with no change to the agent.
Combine them
The forms combine: /gateway/mcp/github?tags=read-only gives an agent only GitHub's read-only tools.
An agent that needs several separate sets configures one connection for each:
{
"mcpServers": {
"github": { "url": "https://your-gateway-url/gateway/mcp/github" },
"dev": { "url": "https://your-gateway-url/gateway/mcp?tags=dev" },
},
}You don't have to write these by hand. The connect dialog's Connect to, Upstreams, and Tags pickers build the URL for you. See Scope a connection.
What a scoped gateway doesn't change
A scoped gateway narrows what the agent asks for. It doesn't grant or remove access, so it isn't a substitute for a rule.
- Your rules still decide. Every URL is filtered for the person calling it, so a tool your rules deny never appears in the list, and two people on the same URL can see different tools.
- Sign-in works the same. Each URL serves its own OAuth discovery metadata, so agents sign in the same way on any of them. See Authenticate agents to the MCP gateway.
- A failing server drops out. Tools from a server whose discovery is failing are missing until it recovers.
Next steps
You can now give each agent the scoped gateway that matches the tools it needs. Next, connect the agent with that URL.
- Connect an agent – connect an agent, with the scope picker
- Tool search – keep a long tool list out of the agent's context instead