.png?fit=max&auto=format&n=gKqTvJPtsRi2bLNx&q=85&s=8abbce3efb590630de2102c43d32aadf)
.png?fit=max&auto=format&n=Dy9YsIECUbR9JZiT&q=85&s=a1f404cd7f7aeb1727c89d81137ae1ac)
There is no single right way to deploy gateways in MCP Manager. The best setup depends on how your teams work, how many MCP servers you plan to connect, and how much control you want at each layer. This guide walks through the common strategies, when each makes sense, and the trade-offs to watch for. Whichever you choose, the security guarantees are the same — per-user identity (or a shared service account when you choose it), logs that always tie back to a real person, and the ability to enable or disable anything in real time. The strategy is about packaging and experience, not the level of security you get.Documentation Index
Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
Use this file to discover all available pages before exploring further.
Creating gateways and assigning servers is part of the Basic gateway management capability; making a gateway available to a team uses Manage team-gateway provisioning. If you can’t create or provision gateways, your role lacks the relevant capability — access depends on the capability, not on any fixed role name. See the capabilities reference.
First, the building blocks
A quick refresher so the strategies make sense:- MCP servers are your back of house. Adding a server to MCP Manager does not expose it to anyone — it just registers it so you can decide what to do with it.
- Gateways are your front of house. A gateway packages one or more servers and is the only way users actually connect. This is where you provision which tools are available (see Feature Governance) and which rules apply.
- Teams are how you grant access. Assigning a gateway to a team makes it available to everyone on that team, and teams can sync from your identity provider through SCIM.
- Roles are what a person can do with the gateways they have. Roles are independent of teams, so you can give the same gateway to two teams while controlling capabilities separately.
How users connect: two URL modes
Before choosing a topology, know that you control whether a user picks a gateway or lands in a specific one. Both use the same base URL with one optional parameter. Picker URL (no gateway specified). The user sees every gateway their team membership grants and chooses one. This pairs naturally with a single company-wide connector: distribute one URL to everyone and let team assignments route people to the right place. If a user’s teams map to only one gateway, that is effectively the only option they see.Picker URL
Locked URL
Strategy 1: One gateway for the whole organization
What it is. A single gateway holds every server you want broadly available, and you distribute one connector to the entire company. Why pick it. The simplest possible rollout — one link to communicate, one connector to manage, and users never think about which gateway to use. Modern AI clients trim and discover tools well at runtime, so a large catalog behind one connector is far less of a cost or performance burden than it used to be. A strong default when most of your team needs broadly the same tools, or when you’re early in your rollout and want minimal overhead. Watch out for. Everyone behind the gateway shares the same provisioned tool set and the same gateway-level rules. Per-user identity and roles still scope what each individual can actually do, so it isn’t a free-for-all — but if different groups need genuinely different tool subsets or guardrails, you’ll eventually want to split them out. Very large tool catalogs can also add context overhead for clients that don’t trim well.Strategy 2: One gateway per team
What it is. A gateway for each department or function (Sales, Legal, Engineering, IT), each containing the servers and tool subsets that group needs, with policies tuned to them. Why pick it. A clean mental model that mirrors your org chart. Each team gets exactly the tools relevant to them and nothing else, reducing context bloat and narrowing the security surface. You can apply different guardrails per team — for example, stricter PII redaction for a group that touches customer data. Hand each team a locked URL so they drop straight into their gateway, and let team membership (synced from your IdP) do the routing as you grow. Watch out for. More gateways to maintain. Cross-team work is a little awkward: someone on two teams either sees two connectors or relies on the picker URL. And if your teams need mostly the same tools anyway, the per-team split is overhead without much payoff.Strategy 3: One gateway per MCP server
What it is. A one-to-one mapping — each gateway exposes a single MCP server (one for Atlassian, one for Google Workspace, one for Slack, and so on). Why pick it. Maximum isolation and the most granular control. Switch any single integration on or off instantly without touching the others, govern each with its own rules, and reason about each independently. Especially useful during evaluation: stand a new server up in its own gateway, put it through its paces, and decide later. Also a good fit for a small number of high-sensitivity servers you want walled off, and it makes auditing one integration at a time straightforward. Watch out for. The most connectors for end users to manage. If someone needs five servers, that’s five connectors and five connections to establish. At scale that’s heavier for everyone — so this works best as a staging and preview pattern, or for a handful of sensitive servers, rather than the whole-company default.Strategy 4: One gateway per use case or work stream
What it is. A hybrid. You build a gateway around a workflow or project that cuts across teams, bundling only the servers and tools that workflow needs, regardless of which department people sit in. Why pick it. Some work doesn’t follow the org chart. A cross-functional project or a specific agentic workflow may need a curated set of tools drawn from several servers. A use-case gateway delivers exactly that set to exactly the people on that work stream, keeping the toolset tight and purpose-built — which helps both security and agent performance, since the agent only ever sees the tools it actually needs. Watch out for. These can proliferate if every short-lived project spins one up. Reserve the pattern for durable, important workflows rather than every passing effort.Quick comparison
| If you want | Use this |
|---|---|
| The simplest rollout, with one link to manage | One organization-wide gateway |
| Tools and policies tailored to each department | One gateway per team |
| Maximum isolation, plus easy evaluation of new or sensitive servers | One gateway per server |
| A curated toolset for a workflow that spans teams | One gateway per use case |
You are not locked in
Most organizations don’t pick one strategy and stop. A very common path is to start simple with a single gateway, then split out per-team or per-use-case gateways as needs diverge. Because access is always governed by the combination of team, role, and per-user identity, and because every change takes effect in real time, you can evolve your topology without disrupting people who are already connected. If you’re not sure where to begin, start with one gateway and the picker URL. It’s the lowest-effort setup, and it’s easy to grow from there.Further reading
MCP Gateways
What a gateway is and how it aggregates servers, brokers identity, and applies rules.
Teams
How provisioning a gateway to a team grants access, and how access resolves across teams.
Roles
How roles control what a person can do with the gateways they can reach.
Feature Governance
Provisioning which tools each gateway exposes, per server.