Credentials and the Capability Ladder

Access is controlled by a credential and the capability it carries. The capabilities form a ladder, not a set of independent flags: each level includes everything below it.

Where to find it

Credentials and their capabilities are held in the MCP datastore, opened from All Datastores in the Architect Panel. There is no dedicated panel section for MCP.

The rungs

• None — no access. The default.
• Read — look things up.
• Write — create and change records, and everything Read allows.
• Admin — everything above, plus administrative operations.

Because it is a ladder, a credential with Admin can read without also being granted Read. The corresponding OAuth scopes are mcp:read, mcp:write and mcp:admin, and a broader scope implies the narrower ones as the specification requires.

Permissions still apply

Capability is a ceiling, not a grant. A credential carrying Write still only reaches datastores its underlying permissions allow — the two combine, and the more restrictive wins. This is what lets you issue a credential for one narrow purpose without it becoming a general key.

Issuing credentials

One credential per client and purpose. A shared credential used by three integrations cannot be revoked without breaking all three, and its log tells you nothing about who did what.

Start read-only

Give a new client Read and see what it does with it. Most useful AI integrations are read-heavy, and the ones that genuinely need Write are worth thinking about deliberately rather than granting by default.

Dynamic client registration

The server supports the standard dynamic registration flow, so a client can register itself rather than being configured by hand. Convenient, and worth understanding before you enable it — decide whether self-registration suits your risk appetite.