# Scopes & the tool list

> The tool list is scope-filtered: a credential only sees the tools it can actually call.

Product: Clad MCP
Source: https://docs.useclad.ai/mcp/scopes

---

The MCP server reuses the API [scope taxonomy](/api/scopes) 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).