MCP Permissions

Three scopes

OAuth grants and fjk_ API keys use the same three scopes. You pick them at consent (OAuth) or when you create/edit a key. Every MCP tool is tagged with exactly one:

delete is split out from write because it's the only class of tool that destroys data. Scopes don't stack into tiers: delete doesn't imply write, and write doesn't imply read. A key needs each scope it uses, explicitly.

Calling a tool without the scope it requires fails before any lookup or mutation runs, with an error naming what's missing and what the principal is allowed to do. See Troubleshooting for the exact message.

Scope is not the only gate

Configuration tools also require workspace OWNER or ADMIN, matching the dashboard. A CONTRIBUTOR holding write can create and edit posts, change status, tag posts, and comment, but cannot create, update, or delete boards, statuses, or tags, reorder them, create, update, or publish changelog entries, or merge, move, feature, reassign, or delete posts. Pinning a comment or marking it internal is also OWNER/ADMIN. Those calls fail with a permission error even though the scope is present. API keys are treated as ADMIN; the role gate only varies for OAuth grants. See MCP Tools for the full split.

Connectors are not scopes

The URL picks the connector. The key or OAuth grant picks the scopes. Both apply.

A read+write key on the Writer URL still cannot call get_post. tools/list hides it; a direct tools/call is forbidden. Writer never returns customer fields, even when the key has read.

A read-only key on the Writer URL can see write tools in the list. The call fails on scope. Grant write (and delete if you need it) on keys you use with Writer.

Keep Reader and Writer in separate chats. See MCP Server.

What the split protects against

The connector is the URL, not the token. The same key works on both, and the boundary holds because an agent cannot change the URL it was configured with partway through a conversation. That is the threat it closes: a feedback post with instructions inside it cannot make a Reader chat mutate anything, because the mutation tools are not in that session at all.

It is not a defence against a hostile client or a leaked key. Anyone holding a write-scoped key can point it at Writer themselves. Scopes cover that case: a read-only key cannot write from any URL.

Choosing and changing scopes

OAuth. Pick scopes on the consent screen. Reader (/mcp/reader/) only offers read — Write and Delete do not appear. Writer and Combined still offer write and delete; write starts checked when the app asked for it, delete starts unchecked. A contributor cannot grant delete. To change the grant, revoke the app under Dashboard -> Developers -> MCP -> Connected apps and approve again.

API keys. Pick scopes when you create a key at Dashboard -> Developers -> API keys. You can edit a key's scopes any time from the same page - the change applies immediately, no need to reissue the key.

Default to read-only for anything that just looks things up. Add write for triage and content-creation agents. Add delete only for principals you trust to remove things permanently - most workflows never need it.

Keys created before scopes existed

The MCP server shipped before per-key scopes did. Any key created before that has no scopes stored on it, and is grandfathered to read + write, no delete - the tools it could already call keep working, and nothing gains the ability to permanently destroy data it couldn't touch before. Grandfathering never includes delete; grant it explicitly if a legacy key needs it.