How to set up team-based access control with gateways – MCP Manager

Why Organize Gateways by Team?

When organizations first adopt MCP Manager, the most natural instinct is to create one gateway per MCP server — a "Slack gateway," a "Jira gateway," a "GitHub gateway." This feels tidy, but it creates problems as you scale:

Connection overload — Each user ends up with five, ten, or more gateway URLs in their IDE configuration. Every gateway is a separate MCP connection that the AI client has to initialize and maintain.
No meaningful access boundaries — A "Slack gateway" doesn't tell you anything about who should use it or what they should do with it. You end up layering team restrictions on top of server-oriented gateways, which gets confusing fast.
Tool sprawl — If every user connects to every gateway, the AI model receives the combined tool definitions from all of them. Major AI providers recommend keeping the total tool count below approximately 40 — beyond that, token costs increase, latency rises, and the model's accuracy in selecting the right tool degrades.
Policy fragmentation — Security rules and logging policies need to be duplicated across every gateway instead of being managed per team.

The pattern that works best — and the one most MCP Manager customers converge on — is one gateway per team. Each gateway bundles all the MCP servers and tools that a specific team needs, with exactly the right permissions. Users connect to a single URL, and MCP Manager routes them to the right gateway based on their team membership.

This approach means fewer connections per user, cleaner access boundaries, and policies that map directly to your org chart.

Step-by-Step: Set Up Team-Based Gateways

Step 1: Plan Your Teams Around Capabilities

Before creating anything in MCP Manager, decide which groups of people need which capabilities. Think in terms of roles and workflows, not servers:

Engineering — Needs GitHub for code, Jira for tickets, Slack for communication, and maybe a documentation server like Context7.
Product — Needs Jira for roadmap tracking, Linear for tickets, and analytics tools — but only read access to GitHub (no write operations).
Support — Needs Intercom and Stripe with full and read-only access, respectively

Notice that multiple teams might use the same MCP server (like Jira), but with different tool allowlists. This is exactly what team-based gateways enable.

Step 2: Create Teams in the People Tab

Navigate to Settings → People → Teams and create a team for each group you identified:

Click "Add Team" and give it a descriptive name (e.g., "Engineering," "Product," "Support").
Assign members — Add users to the team. Users can belong to multiple teams if they wear multiple hats (e.g., a tech lead who needs both Engineering and Product capabilities).

If your organization uses an identity provider with SCIM (like Okta or Entra ID), team membership can sync automatically — when someone joins or leaves a group in your IdP, their MCP Manager team membership updates to match.

Step 3: Create a Gateway for Each Team

Navigate to Settings → Gateways and create one gateway per team:

Click "Add Gateway" and name it to match the team (e.g., "Engineering Gateway").
Assign the gateway to its team — This ensures only members of that team can see and connect to this gateway.

Step 4: Assign MCP Servers and Configure Tool Allowlists

Open your new gateway and go to the Servers tab. Here you assign the MCP servers this team needs and control exactly which tools are exposed:

Add servers — Assign each MCP server the team needs to the gateway. The same server can be assigned to multiple gateways, so your "Jira" server configuration can appear in both the Engineering and Product gateways.
Configure the tool allowlist per server — For each assigned server, you can selectively enable or disable individual tools, resources, and prompts. MCP Manager discovers all available features when a server is assigned, and you choose which ones this team should have access to.

For example, your Product team's gateway might include the GitHub server but with only read-oriented tools enabled (like search_code and get_file_contents), while the Engineering gateway enables the full set including create_pull_request and push_files.

This is also where tool provisioning gives you practical benefits:

Fewer tools = better AI performance — A support team doesn't need 30 GitHub tools cluttering their AI context. Disabling irrelevant tools improves response speed and accuracy.
Lower token costs — Every tool definition sent to the AI model consumes tokens. Trimming unused tools directly reduces per-request costs.
Rug pull protection — MCP Manager snapshots each approved tool's name and description. If an upstream server silently changes a tool's definition (a potential supply chain attack), MCP Manager can automatically disable it and alert administrators.

The Identity Model: Shared vs. Personal

When you assign an MCP server to a gateway, you also choose how users authenticate with that server. MCP Manager supports two identity schemes, and the right choice depends on the server and your security requirements.

Personal Identity (Bring Your Own)

Each user authenticates individually with the MCP server using their own credentials. The first time a user connects through the gateway, they are prompted to authorize access — typically via an OAuth flow that redirects to the server's website (e.g., clicking "Approve" on Atlassian's authorization page) or by providing a personal API token.

Use personal identity when:

The server supports OAuth and you want actions attributed to individual users (e.g., a Jira comment shows who actually wrote it, not a generic service account).
Users have different permission levels in the upstream service and you want those to carry through (e.g., a junior developer can't merge to main in GitHub even through MCP Manager).
Compliance requires individual audit trails — every action is traceable to a specific person.

Shared Identity

A single pre-configured identity (typically an API key or service account token) is used for all users connecting through the gateway. Users don't need to authenticate with the server individually — the gateway handles it transparently.

Use shared identity when:

The MCP server doesn't support OAuth or per-user authentication (e.g., a self-hosted server that only accepts a single API key).
You're connecting to a shared resource where individual attribution isn't necessary (e.g., a documentation search server or an internal knowledge base).
You want to simplify onboarding — new team members connect to the gateway and immediately have access without needing to set up their own credentials for every server.
The server is read-only and there's no security benefit to individual credentials.

You can mix identity schemes within a single gateway. For example, your Engineering gateway might use personal identity for GitHub (so commits are attributed correctly) and shared identity for a documentation server (where everyone gets the same read-only access).

The Universal Single-Gateway URL

One of the most powerful aspects of the team-based approach is that every user can connect to the same base URL:

https://mcp.mcpmanager.ai/gateway/v1/mcp

When a user connects to this URL, MCP Manager identifies them through the authentication flow and determines which gateways are available based on their team membership. If they belong to exactly one team with one gateway, the connection is established automatically. If they have access to multiple gateways, the authorization screen lets them choose which one to connect to.

This simplifies deployment significantly:

One URL for everyone — Instead of distributing different gateway URLs to different teams, you can put a single URL in your organization's standard IDE configuration or onboarding docs.
Capabilities follow the person — When someone moves teams, you update their team membership in MCP Manager (or it syncs automatically via SCIM) and they get the right tools on their next connection. No URL changes needed.
Simpler client configuration — A single entry in mcp.json is all anyone needs:

{ "mcpmanager": { "url": "https://mcp.mcpmanager.ai/gateway/v1/mcp", "type": "http" } }

Or with the Claude Code CLI:

claude mcp add --transport http mcpmanager https://mcp.mcpmanager.ai/gateway/v1/mcp

You can also use gateway-specific URLs (https://mcp.mcpmanager.ai/gateway/v1/mcp?gateway=CSO-xxxxxxxx) if you need a user to connect to a specific gateway directly — for example, when someone belongs to multiple teams and you want to pre-select the right gateway without prompting them.

Putting It All Together: An Example

Here's what a typical setup looks like for an organization with three teams:

Engineering Team

Gateway: "Engineering Gateway"
Servers: GitHub (full tool access, personal identity via OAuth), Jira (full access, personal identity), Slack (read + post messages, personal identity), Context7 (all tools, shared identity)
Policies: Presidio PII detection on outbound requests, regex rules to catch API keys in tool inputs

Product Team

Gateway: "Product Gateway"
Servers: GitHub (read-only tools only, personal identity), Jira (full access, personal identity)
Policies: Presidio PII detection, alert-only mode for new Intercom integration

Support Team

Gateway: "Support Gateway"
Servers: Intercom (full access, personal identity), Stripe (read-only, personal identity), Internal Docs (full access, shared identity)
Policies: Presidio PII detection with block mode, regex rules to redact customer credit card numbers

All three teams use the same base URL in their IDE configuration. When an engineer connects, they see the Engineering Gateway's tools. When a support agent connects, they see the Support Gateway's tools. No one sees tools they don't need, and security policies are tailored to each team's risk profile.

Tips for Scaling

Start with teams, not servers. List the teams in your organization first, then decide which MCP servers each team needs. This prevents the common mistake of creating server-oriented gateways and retrofitting team access later.
Use tool allowlists aggressively. Most MCP servers expose more tools than any single team needs. Trimming the list keeps your AI model fast and accurate, and reduces your security surface area.
Default to personal identity for write operations. If a server allows creating, modifying, or deleting data, use personal identity so actions are attributed to the right person. Reserve shared identity for read-only or low-risk servers.
Roll out policies in alert-only mode first. When adding new security rules, start with alert-only to see what triggers against live traffic before switching to block or redact mode.
Need more advanced user management? Reach out to us about SSO and SCIM.