Snap Ads MCP read-only: can an agent write to my account?
No: Snap says this release is read-only, so an agent can read Snapchat Ads data but cannot create, update or delete anything. What that means in practice.
No, an agent cannot write to your Snapchat Ads account through the Snap Ads MCP server today. Snap's documentation says: "This release is read-only: an agent can read your Snapchat Ads data but cannot create, update, or delete anything."
That sentence is from Snap's Ads MCP introduction, read 2026-09-29. Everything about Snap below comes from Snap's own pages; the Sume comparison comes from the MCP tools and gates docs.
What does read-only rule out?
Three verbs are named: create, update and delete. In ad terms that means the agent cannot launch a campaign, edit a budget or creative, or remove anything. A request phrased that way will not be carried out by this server, whatever the client. If a pipeline needs a change, a person makes it in Snapchat's own tools.
What is the scope behind it?
Snap's setup page lists one scope for every agent: snapads.read. Whichever client you use, the config asks for that scope only, and the setup pages give no write scope to add. Snap's docs say write access is planned, but they give no date, so do not build a plan that depends on it.
Does read-only mean an agent sees every account?
No. Read-only describes what an agent may do; the account list is a separate question. Snap says members only access ad accounts their existing Snapchat permissions allow, and an Admin or Business Admin has to approve the agent for the organization first. Being read-only does not widen what a user can see.
How does that compare with a read-only Sume MCP session?
Sume draws the line by OAuth scope. Default hosted OAuth grants read-only access (mcp:read), and the user turns Write on at the consent screen to also receive mcp:write. With mcp:read only, write tools and paid tools such as generate_image return insufficient_scope. Details are in OAuth and API keys.
| Snapchat Ads MCP | Sume MCP | |
|---|---|---|
| Read scope | snapads.read | mcp:read (required) |
| Write | Not in this release; planned | mcp:write, opt-in at consent |
| Blocked call | Cannot create, update or delete | Returns insufficient_scope |
Which clients does this apply to?
All of them. Snap's connect page gives each agent its own client id (claude-snap-ads for Claude, codex-snap-ads for Codex, chatgpt-snap-ads, gemini-snap-ads and antigravity-snap-ads), and it names snapads.read as the scope for all agents. Read-only is a property of the server release, not of a particular client, so switching from Claude to Codex does not unlock writes. For per-client setup, see Snapchat Ads MCP in Claude.
One practical check: after signing in, ask the agent to list the tools it can call. If a tool name suggests a create or update action, treat the server's statement as the rule and expect the call to fail rather than assume it works.
What is a sensible job for a read-only ads agent?
Reporting and questions: summarize what is running, spot accounts that need attention, draft the note a person will act on. Pair it with a server that can produce creative, and a human closes the loop by uploading. That pattern is in using two MCP servers in one agent.
Sources
Related posts
More in Integrations
- Spring Retry and @Retryable for a paid API call in Spring 7
Spring Retry is archived; Spring Framework 7 has @Retryable in core. For a paid API call, narrow the exceptions, back off, and pass one idempotency key in.
- Stripe checkout webhook: start a paid job once per payment
Listen for checkout.session.completed, verify the signature on the raw body, answer 2xx fast, then start the job keyed by the Checkout Session id.
- Suno MCP: making music from Claude, and what Sume's MCP has
No Suno MCP server is in Sume's docs. Sume's hosted MCP does expose a music_create tool for Lyria-based music, and paid calls need an idempotency_key.
- Tenacity retry in Python: safe settings for a paid API POST
Bare @retry in tenacity retries forever with no wait. For a paid POST, cap attempts, add jittered backoff, retry only transient errors, and reuse one key.
Written by Sume