Skip to main content

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.

This tutorial builds MCP Manager’s access model end to end: create a team, build a gateway scoped to it, choose which of a server’s tools it exposes, invite a teammate, and confirm they see exactly that gateway. You’ll work with the three pieces that decide who-can-do-what: teams, gateways, and the per-server tool allowlist.
This tutorial uses Manage people (to create teams and invite users) and Basic gateway management (to build and provision a gateway). If those pages or buttons aren’t visible, your role lacks the capability — access depends on the capability, not on a role name. See the capabilities reference.

​
What you’ll need

  • An MCP Manager workspace with at least one MCP server already added. If you don’t have one, do Your first governed tool call first — you can reuse the docs server from it.
  • A colleague’s email address to invite (or a second address of your own).
  • About 15 minutes.

​
Step 1: Create a team

A team grants access: put a gateway in front of a team, and everyone on that team can reach it.
1

Open the Teams tab

Go to People and open the Teams tab.
2

Create it

Click Create. In the Add a team dialog, set Team name to Engineering, then click Save this team.

​
Step 2: Build a gateway for the team

1

Create the gateway

Go to Gateways, click Add, and in Add a gateway set Gateway name to Engineering.
2

Provision it to the team

Under Provision access to teams, select Engineering, then click Save this gateway. Only members of a team you provision here will see this gateway when they connect.

​
Step 3: Assign a server and choose its identity scheme

Open the Engineering gateway, go to its Servers tab, and click Assign a server (the docs server from the quickstart works, or any server you’ve connected). When you assign it, you choose its Identity Scheme — how users authenticate to the upstream service. Choose Each user uses their own identity for anything that writes data or where an audit must name the individual; choose One identity is shared by everyone for read-only or low-risk servers. You can mix schemes across servers in the same gateway. For the full picture, see Identity Controls.

​
Step 4: Review capabilities and pin the tools you want

With Each user uses their own identity selected, pick an identity below it to preview. MCP Manager shows the capabilities that came in from the server for that identity, split into the three things an MCP server provides a client: tools, resources, and prompts. Each of those sections defaults to Allow all and shows the Available tools tab — every capability discovered from the server for that identity. To narrow it, switch the section to Allow if conditions are met:
1

Find the tools to allow

On the Available tools tab, search by name and select the tools you want — one at a time, or check several to bulk-select.
2

Add them as conditions

Add a tool on its own, or with several checked, click Add N conditions. Each condition asks what to match on: the tool’s name, its description, or both.
3

Confirm what's exposed

The Provisioned tools tab shows the tools that will be available to users connected to this gateway, and the Conditions tab lists the conditions you added.
Choosing what a condition matches on is metadata pinning. Pin only the name, and a tool keeps flowing through even if its description changes upstream. Pin the description (or both), and any upstream change stops the tool until you review it. That guards against a server silently altering a tool — a rug pull — and it keeps agents’ skill files, which reference tools by name, from drifting out of sync with what the gateway actually exposes.
Every tool a client loads consumes context tokens and gives the model another way to pick wrong, so a tight, purpose-built tool set is both cheaper and more accurate. Expose what the team needs and nothing more.
The gateway is the atomic unit of tool governance. If a second team needs a different slice of the same server, give them their own gateway with its own conditions rather than scoping tools per person within one gateway — the same server can sit in as many gateways as you like.

​
Step 5: Invite a teammate

1

Open the invite dialog

Go to People, open the Users tab, and click Add new users.
2

Enter their details

In Email address(es), enter one or more comma-separated addresses. Choose a Role (it applies to everyone in this batch), and under Assign to teams select Engineering. Click Send via email. Each person gets an invitation immediately.
Everyone in a single invitation gets the same role. To assign different roles, send separate invitations. If your organization syncs from an identity provider, team membership can instead flow in automatically through SCIM.

​
Step 6: Confirm the scoping

Have your teammate accept the invitation, then connect their client using the Engineering gateway’s URL — copied from its overview page, including its gateway parameter (see Connect your AI client to a gateway). They land directly in Engineering and reach only the gateways their teams grant. The tools available to them are exactly the ones you allowed in Step 4.
You built the full chain: a team grants access to a gateway, the gateway exposes a deliberately pinned set of a server’s tools under a chosen identity scheme, and a teammate you invited lands in exactly that gateway with exactly those tools. Change the team, the conditions, or the membership at any time and it takes effect on the next connection — no URLs to reissue.

​
Further reading

Add your first gateway rule

Put a guardrail on the gateway you just built.

Identity Controls

Personal versus shared identity in depth, and how credentials are brokered.

Feature Governance

The full reference for allowing tools, resources, and prompts per server.

Teams

How team membership resolves access across one or many teams.