Auth & scopes
How OAuth works for the MCP server, scopes granted, token lifecycle, revocation.
The AdCrunch MCP server is OAuth-protected. Your AI client (Claude Desktop,
Cursor, ChatGPT, …) goes through a standard OAuth 2.1 PKCE flow with
security.adcrunch.dev and receives a short-lived bearer token plus a refresh
token.
Scopes
OpenID Connect scopes identify you; AdCrunch service scopes gate what the tools can touch. You see one consent row per requested scope when you connect a client.
openid,profile,email— identifies your account.insight:read— read your organization’s connected ad-account performance (list_advertisers,list_entities,get_entity,query_insights).skill:read— read your organization’s ad-ops playbooks (skill_list,skill_get).skill:write— create, edit, and delete your playbooks (skill_create,skill_update,skill_delete).asset:read— list your organization’s source media and where it’s registered (asset_list,asset_get).asset:write— upload media and register it into an ad account’s library (asset_create_upload,asset_finalize,asset_register).
Read and write scopes are separate consent rows
Most AdCrunch tools are read-only. The write scopes — skill:write and
asset:write — each appear as their own consent row, so you grant them only
to clients you want authoring playbooks or bringing in creative. A client with
only the matching …:read scope can look but not change anything.
asset:write covers both uploading and registering, but it does not grant
ad-account mutations: an Asset landing in a library changes no delivery and
spends no money.
Token lifecycle
(todo: TTL, refresh behavior, revocation flow from the console)
Revoking access
Console → Account → Connected apps. Revoke any AI client and the next tool
call from that client returns 401.