Two questions get asked about every request, and they are genuinely 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.
| Grantee | Use it when |
|---|---|
| A person | One individual needs one tool |
| A team | The grant should follow team membership |
| 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.
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.