Roles and Permissions
Roles decide what people can do. LockMCP separates this into two layers that are easy to confuse but do different jobs:
- Permissions — what someone can do in the dashboard (upload specs, invite members, manage billing)
- Tool access — which tools their AI client may call
A role carries both. Find it all at Dashboard → Members & Access, which has three tabs: Members, Roles and Permissions.
The two default roles
Every workspace starts with two:
| Role | Intended for |
|---|---|
| Admin | Full administrative access — the people running the workspace |
| Member | Everyday users who call tools but don't configure anything |
You can create more, and you should as soon as different groups need different tool access.
Permissions
Permissions are dashboard capabilities, expressed as slugs grouped by area:
| Area | Permissions | Allows |
|---|---|---|
| Connections | connections.read, connections.write | View / create and configure connections |
| Tools | tools.read, tools.publish | View tools / publish and unpublish them |
| Specs | specs.upload | Upload OpenAPI specs |
| Members | members.invite, members.manage | Invite people / manage and remove them |
| API keys | api-keys.manage | Manage API keys |
| Settings | tenant.settings.read, tenant.settings.manage | View / change workspace settings |
| Billing | billing.read, billing.manage | View / change plan and payment |
Admin holds all of them. Member holds only the read-oriented subset — connections.read, tools.read, tenant.settings.read, billing.read — so a member can see the workspace but not reconfigure it.
Edit a role's permissions from the Roles tab → Permissions.
Tool access is separate
This is the distinction worth internalising:
| Governs | Set where | |
|---|---|---|
| Permissions | The dashboard | Roles tab → Permissions |
| Tool access | What AI clients may call | Roles tab → Tools, or the Tool Catalog |
A role with every permission but no tool access can administer the workspace and see nothing from an AI client. A role with no permissions but broad tool access is the opposite — and is often exactly what you want for end users.
Granting tools.read does not grant access to any tool. See Assigning Tool Access.
Creating a role
Roles tab → Create Role. Give it a name, set its permissions, then grant it tool access.
Quick Setup creates a role with a sensible starting configuration if you'd rather adjust than build from scratch.
Per-role actions:
| Action | Does |
|---|---|
| Edit | Rename or change the role's details |
| Permissions | Set dashboard capabilities |
| Tools | Set which tools the role may call |
| Delete | Remove the role |
Designing roles
Start from what people do, not from your org chart.
A workable pattern for most workspaces:
| Role | Permissions | Tool access |
|---|---|---|
| Admin | All | All |
| Operator | connections.read, tools.read | Read + routine write tools |
| Analyst | connections.read, tools.read | Read-only tools |
| Member | Defaults | Whatever that group genuinely needs |
Two principles worth holding to:
Grant the narrowest tool access that works. An AI client will eventually call anything it can see. Restricting the tool list is more reliable than hoping the model shows restraint.
Keep destructive tools in their own role. If delete_customer is published, only one narrow role should reach it — rather than it riding along with everything else in a general-purpose role.
Multiple roles per member
Members can hold several roles, and access is the union — a member with Analyst and Operator can call every tool either role permits.
Convenient, but it means adding a role only ever widens access. To reduce what someone can do, remove a role rather than adding a narrower one.
Roles and connections
Roles are workspace-level; tool access is per tool, and tools belong to connections. So one role can hold different access across different connections — full access to your internal API, read-only on the customer-facing one.
For Tenant Delegated connections you can additionally map your app's role names onto LockMCP roles in wizard Step 3, so people arrive with the right role automatically. Unmapped role names are ignored — they don't fall back to a default, which is a common cause of "signed in but has no access".
Where to go next
- Inviting Members — adding people
- Assigning Tool Access — the other half of access
- Tool Catalog — publishing tools in the first place