Roles and permissions

https://docs-dev.evohub.io/mcp

claude mcp add --transport http evohub-docs-docs https://docs-dev.evohub.io/mcp

{
  "mcpServers": {
    "evohub-docs-docs": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://docs-dev.evohub.io/mcp"
      ]
    }
  }
}

{
  "mcpServers": {
    "evohub-docs-docs": {
      "url": "https://docs-dev.evohub.io/mcp"
    }
  }
}

{
  "servers": {
    "evohub-docs-docs": {
      "type": "http",
      "url": "https://docs-dev.evohub.io/mcp"
    }
  }
}

Access in EvoHub is decided by organization roles. A role is a named set of permissions, and you give roles to people or to teams. This page explains the default roles, how to build your own, and the full list of permissions per product.

#How access works

• Every permission check is made by EvoHub's servers, not only by the console. Hiding a button is a convenience; the API refuses the same action.
• A refused action returns 403 Forbidden. You stay signed in; you are simply not allowed to do that. See Errors.
• What a person can do is the sum of every role they hold, directly or through their teams.
• Roles belong to the organization. The same person can be an Admin in one organization and a Viewer in another.
• Docs sites and changelogs have no roles of their own. Access to them comes from organization roles like everything else.

#Owner and the default roles

Every organization starts with three default roles. They are marked (default) in role pickers.

What the default roles allow, product by product:

Administrators can change what the Member and Viewer roles (and the Admin role) grant; everyone holding the role gets the change. Default roles cannot be renamed or deleted.

#Custom roles

Build a custom role when the default roles are too broad or too narrow, for example "Can respond to alerts but not edit schedules" or "Billing only".

Rules that apply to every role:

• You can only grant what you hold. Permissions you do not hold yourself are greyed out, and the server refuses a role that would give someone more than you have. Only an administrator can give someone the Admin role.
• A write brings its read. Selecting a write permission also selects the read it needs, so a role never ends up able to edit something it cannot open.
• Creating and editing roles needs the Roles → Write permission. Owners and Admins have it; you can give it to others with a custom role.

#Ready-made roles

The role editor offers ready-made levels for each product. Clicking one fills in its permissions; every box stays editable afterwards.

#Permissions reference

Permissions are grouped by product, as in the role editor. Each has an identifier, which you also see on API keys.

A few things need no permission at all: every member can see who else is in the organization, see the teams they belong to, open support tickets, and manage their own profile, notifications, sessions, two-factor authentication and personal API keys.

#Related

• Organizations and teams
• API keys and scopes
• Errors