Two questions get asked about every request, and they are different:
Passing the first says nothing about the second. A member of the owning organization can see a server exists and still be refused the right to deploy it.
A freshly installed server is reachable by nobody, including the person who installed it. That is deliberate: a default that grants access is a default nobody reviews.
An MCP server exposing twelve tools is twelve separate decisions. You can grant
search_issues to everyone in engineering and create_release to two people,
on the same server.
The gateway checks the specific tool named in the request. Reaching the server is not permission to call everything on it.
A grant on the server covers every tool on it. A grant on a single tool covers that tool alone. Either one is enough for the server to show up for you: you can use a server when you hold it, or hold any one of its tools.
| Grantee | Use it when |
|---|---|
| A person | One individual needs one tool |
| A team | The grant should follow team membership (Settings → Teams → a team → MCP servers) |
| An access group | A named bundle of grants you reuse |
Grants resolve through the platform's roles, so removing someone from a team removes their access at the same moment. There is no second list to remember.
A team grant gives every member the server and all its tools. A person's own deny still wins over a team grant, so one member can be held back without taking the server away from the rest of the team.
Your AI clients are only configured with servers you can use. The desktop app
and mcphub config sync write servers you hold access to and leave the rest
out, so an agent never sees a server the gateway would refuse. When you are
granted a new server it appears in your clients on the next sync; when a grant
is removed it disappears.
To see the whole picture (every server in the organization, which ones you can use, and the tools each exposes), open Servers in the desktop app or run:
Above per-tool grants sit the levels that decide administrative authority:
| Level | Can |
|---|---|
| Member | Use tools they have been granted |
| Developer | Install servers, deploy, roll back |
| Admin | Manage members, credentials, billing |
| Owner | Everything, including deleting the organization |
Some actions require a capability as well as a level. Promoting a build to a protected environment needs an approval capability that a developer with full deploy rights does not hold. The separation exists so shipping to production is a second person's decision.
A key acts with the authority of the person who created it. It cannot be granted anything that person does not have, and revoking their grants revokes the key's reach at the same time.
Warning
This is why a key is not a service account. If you need access to outlive an individual, create the key under an account intended for that purpose. A key whose creator leaves the organization stops working.
If the gateway cannot determine whether a caller holds a permission (the platform is unreachable, the principal does not resolve), the request is refused. Failing closed is the only safe direction: refusing a legitimate call is a retryable inconvenience, allowing an illegitimate one is not.
That applies to a call the gateway has never decided. Decisions are cached for 15 seconds, so a grant or revocation takes up to 15 seconds to take effect. During an outage, a decision the gateway already holds keeps being served and is retried every 30 seconds, so an outage does not revoke access that was working a moment ago.