MCP scopes and permissions

Scopes

Every tool declares its required scopes. OAuth-connected clients receive the scopes approved in their grant. A verified PAT receives all capabilities available to external MCP clients, including data:query, because PATs have no OAuth scope selection. Your Astrato permissions and the features enabled for your tenant still determine which resources and operations you can use. A PAT does not expose capabilities reserved for in-product Nash.

Every tool is also listed with MCP behaviour annotations. readOnlyHint is true for a tool that changes nothing. Otherwise destructiveHint says whether it can change, replace, remove, disable or revoke something that already exists, or only creates something new or a restorable version. Clients use them to decide when to ask you first; they grant nothing, and scopes, roles and permissions still decide what a call may do.

• workspace:read — list the current user’s visible collections and workbooks.
• workspace:write — edit or delete collections and workbooks, change workbook collection membership, update Starred, and create data connections.
• sl:read — inspect semantic layers, business questions, datasets, stored filters and data actions.
• sl:write — edit and publish semantic layers.
• sl:version — create versions. Importing a Snowflake semantic view also needs sl:write.
• data:query — prepare and execute queries against published semantic-layer data.
• admin:read — read the users and licence teams in the caller’s own tenant.
• admin:write — change a user’s role, sign-in status and licence team.
• publication:read — list and inspect accessible app publications.
• publication:write — create unpublished app publications and update their metadata; hosting changes additionally require publication:publish.
• publication:publish — unpublish app content or change hosting through MCP; building and uploading replacement content uses the CLI.
• publication:manage-access — inspect and change direct Data App grants through the Management access tools, and open a public Data App’s data with grantPublicDataAccess.

OAuth clients must explicitly request the two administration scopes; they are not baseline grants. Verified PAT sessions receive these scopes with the other grantable external capabilities. For either authentication method, the tools refuse a caller who is not the workspace owner or an administrator of their own tenant — the scope says what the client may attempt, the role says whether the person behind it may.

See Manage Data App publications for publication management and the CLI publishing workflow. These tools are preview capabilities and are omitted from discovery when app publishing is disabled.

tools/list shows every tool registered by the environment regardless of the client’s scopes. Calling a tool without a required scope returns an insufficient_scope error.

The baseline scopes are workspace:read, workspace:write, sl:read, sl:write, sl:version and data:query. An OAuth grant keeps the scopes it was approved with, so a connection authorized before a scope joined the baseline, or by a client configured with a shorter scope list, can lack some of them. astrato_get_context then lists them in auth.missingBaselineScopes, the tools that need them in auth.toolsRequiringMissingScopes, and the remedy in auth.remedy. Reconnect (re-authorize) the connector to obtain them; if your client configuration lists scopes, add the missing ones first. The report grants nothing, and those tools keep returning insufficient_scope until you reconnect.