Scopes & the tool list

The MCP server reuses the API scope taxonomy unchanged, and the tool list itself is scope-filtered: a credential only ever sees the tools it can actually call.

• A read-only grant sees search/get/list tools.
• issues:write adds issue mutations; accounts:write adds CRM writes; and so on per resource.
• Admin-gated scopes (settings:write, webhooks:manage, …) require an admin grant and unlock the settings and webhook tools.

Article create/update tools use articles:write; a request that makes an article both published and public additionally requires articles:publish. Publication is member-eligible and coarse write satisfies the publish scope; a narrowly scoped articles:write key needs the explicit articles:publish grant.

Help-center homepage curation follows the same permission model. Call list_featured_articles before replace_featured_articles: replacement is atomic and complete, so omitted pins are unpinned, while unavailable pins remain listed for explicit preservation. Pass an empty articleIds list to clear manual pins and restore automatic recency. The replacement tool is visible only when the credential satisfies both articles:write and articles:publish. New pins must be live and belong to an included collection; already-pinned unavailable articles may still be retained or reordered.

Because the surface is filtered, an agent can't even attempt a tool it lacks the scope for — there's nothing to call.

Agents should call whoami first. It returns the workspace, the granted scopes, and guidance on what to do if an expected tool is missing (usually: the credential needs a broader scope, or an admin grant).