> ## 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.

# Build a team gateway and invite a teammate

> A hands-on lesson in MCP Manager's access model: create a team, build a gateway for it, provision a server with a trimmed tool allowlist, invite a teammate, and confirm they see only that gateway.

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](/deployment/teams), [gateways](/mcp-gateway-concepts/mcp-gateways), and the per-server [tool allowlist](/security/feature-governance).

<Info>
  This tutorial uses **Manage teams** and **Invite users** (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](/deployment/rbac-and-roles/capabilities).
</Info>

## 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](/tutorials/first-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.

<Steps>
  <Step title="Open the Teams tab">
    Go to [People](https://app.mcpmanager.ai/settings/people) and open the **Teams** tab.
  </Step>

  <Step title="Create it">
    Click **Create**. In the **Add a team** dialog, set **Team name** to `Engineering`, then click **Save this team**.
  </Step>
</Steps>

## Step 2: Build a gateway for the team

<Steps>
  <Step title="Create the gateway">
    Go to [Gateways](https://app.mcpmanager.ai/settings/gateways), click **Add**, and in **Add a gateway** set **Gateway name** to `Engineering`.
  </Step>

  <Step title="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>
</Steps>

## 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.

```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart TD
  Q{"Identity Scheme"}
  Q -->|"Each user uses their own identity"| P["🔑<br/>Each user authorizes as themselves.<br/>Upstream actions and permissions are theirs;<br/>audit logs name the individual."]
  Q -->|"One identity is shared by everyone"| S["🔑<br/>One pre-configured identity serves all users.<br/>Good for read-only or low-risk servers,<br/>or where individual attribution isn't needed upstream (but MCP Manager logs will always indicate the user's account that made each call)."]
  classDef trust fill:#2fedb4,color:#062b4c,stroke:#059669,stroke-width:1.5px;
  class P,S trust;
```

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](/features/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**:

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Note>
  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.
</Note>

<Tip>
  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.
</Tip>

<Note>
  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.
</Note>

## Step 5: Invite a teammate

<Steps>
  <Step title="Open the invite dialog">
    Go to [People](https://app.mcpmanager.ai/settings/people), open the **Users** tab, and click **Add new users**.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Note>
  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](/enterprise/scim).
</Note>

## 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](/tutorials/connect-your-ai-client)). 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.

<Check>
  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.
</Check>

## Further reading

<CardGroup cols={2}>
  <Card title="Add your first gateway rule" icon="shield-halved" href="/tutorials/first-gateway-rule">
    Put a guardrail on the gateway you just built.
  </Card>

  <Card title="Identity Controls" icon="id-badge" href="/features/identity-controls">
    Personal versus shared identity in depth, and how credentials are brokered.
  </Card>

  <Card title="Feature Governance" icon="list-check" href="/security/feature-governance">
    The full reference for allowing tools, resources, and prompts per server.
  </Card>

  <Card title="Teams" icon="users" href="/deployment/teams">
    How team membership resolves access across one or many teams.
  </Card>
</CardGroup>