Gatana logoGatana Docs

Permissions & Roles

Assign granular roles to control access to different servers

Introduction

You can give organization users, service accounts, and teams different levels of access to servers by assigning them to roles. Choose the role that best fits each member or team's function in your organization without giving people more access to the server than they need. For what those three principals are, and how a team grants a role to its members, see People & Teams.

From least access to most access, the roles for an organization's servers are:

  • No Permissions: user cannot see or interact with the server
  • Member: able to see and call the tools
  • Maintainer: able to modify the server configuration
  • Admin: modify permissions and delete the server

Organization owners can set base permissions that apply to all members of an organization when accessing any of the organization's servers. For more information, see How Access Is Decided and Set Base Permissions below.

How Access Is Decided

A member can reach a server for any one of four reasons. An empty member list on a server does not mean nobody can use it.

  1. A membership on the server. The member, or a team they belong to, is added to that server with a role.
  2. A profile. A profile that includes the server is assigned to the member or to one of their teams.
  3. The server's Visibility. A server set to Organization can be used, as Member, by everyone in the organization.
  4. The base role of the organization. If it is anything other than No Permissions, every member holds that role on every server, without being added to anything. See Set Base Permissions below.

A member gets the highest role that any of these reasons gives them. Organization owners have full permissions whatever the four say, with one exception: a session that applies a restrictive profile is narrowed to that profile, owner or not.

Visibility Is Not The Same As Access

A server's Visibility and the organization's base role are two independent ways in. Either one on its own is enough to let every member use a server:

Base roleVisibilityWho can use the server
No PermissionsPrivateOnly the people and teams you added, plus profiles and owners
No PermissionsOrganizationEvery member, as Member
Member, Maintainer or AdminPrivateEvery member, at the base role
Member, Maintainer or AdminOrganizationEvery member, at the base role

To restrict a server to named people only

Set the server's Visibility to Private and the organization's base role to No Permissions. Changing only one of the two leaves the server open to every member.

For narrowing what one client or agent may reach, use a restrictive profile instead.

Base Member Privileges

You can set base permissions that apply to all members of an organization when accessing any of the organization's servers.

To change it, go to Settings in the left sidebar and find Base Member Privileges. In the public API the field is memberDefaultRole on the organization.

A new organization starts at No Permissions. Members then reach a server only through a membership, a profile, or the server's Visibility. Raise the base role when you want everyone to have the same role everywhere without granting it server by server.

If someone with admin access to an organization's server grants a member or a team a higher level of access for the server, the higher level of access overrides the base permission. The base role never lowers a role somebody already has.

Members with the organization role of Owner always have full permissions, whatever the base role is.

Note that all changes to base permissions will affect both new and existing members.

Raising the base role opens every server at once

The base role applies to every server in the organization, including servers added later. Setting it to Admin, for example, lets any member change the configuration of, and delete, every server.

Limiting A Client Or Token

The four reasons above decide what a person may reach. Often one client should reach less than the person running it: an agent that may use a single server, for example.

Use a profile for that. A profile is a named set of servers and tool restrictions, and it can be assigned to a personal access token or attached to a connected client as well as to a user or a team, so one client reaches only what its profile allows. A restrictive profile narrows a session to the servers in that profile and nothing else, including for an organization owner.

Roles cannot be attached to an MCP client's own identity. A client holds no role of its own. Scope what it reaches instead: assign a profile to the personal access token it authenticates with, or attach one to the connected client if it signs in over OAuth.

Server Creation Privileges

In a new organization by default all users are allowed to create servers. You can control this in the organizational settings.

Whoever creates a server becomes its Admin. They can configure it, decide who else reaches it, and delete it, without anybody granting them anything. This matters because a new server is Private and the base role is No Permissions, so without it the creator could not see their own server.

On this page