Skip to main content
Glama
Sign In
Ads MCP for Snapchat

Ads MCP for Snapchat

by Usame794
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

snap_delete

Destructive

Permanently delete a Snapchat campaign, ad squad, ad, or audience after a safety preview; confirm exact name and approval token to apply, since deletion cannot be undone.

Instructions

Permanently delete a campaign, ad squad, ad or audience. Heavily guarded: the item must be PAUSED (audiences excepted), must have spent nothing in the last 30 days, a campaign must have no ACTIVE ad squads, and you must pass confirm_name equal to its exact name. Cannot be undone. Previews (and shows any blockers) unless confirm=true. Two steps: confirm=false returns a preview and an approval_token; to apply, repeat the same arguments with confirm=true and that approval_token.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "entity": "<entity>",
      "id": "<id>"
    },
    "name": "snap_delete"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
entityYes
confirmNofalse = preview only (nothing sent). true = apply; needs approval_token from the preview.
confirm_nameNoExact name of the item, copied from the preview
approval_tokenNoThe approval_token returned by the preview of this exact request. Required with confirm=true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.1

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare destructive=true and openWorld=true, but the description adds substantive guard conditions, irreversibility ("Cannot be undone"), and the two-step preview/approval-token workflow. That is exactly the sort of behavioral context an agent needs before invoking a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded: destructive action first, then guard conditions, then the two-step workflow. Every sentence carries operational information, and there is no redundant prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, multi-step tool with no output schema, the description covers the critical preconditions, irreversibility, and approval-token protocol. It is nearly complete, though the preview response shape beyond approval_token and blockers is only lightly described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 60%, and the description mostly reinforces what the schema already says about confirm, confirm_name, and approval_token. It adds useful procedural meaning around the preview-then-apply loop, but it does not explain id formatting or reconcile the entity list with the schema's "segment" enum value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: "Permanently delete a campaign, ad squad, ad or audience." It clearly identifies the mutation and the supported entity types, which is enough for an agent to distinguish it from read-only or create/clone siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives strong when-to-use context by spelling out the PAUSED requirement, the 30-day no-spend guard, the no-ACTIVE-ad-squads rule for campaigns, and the confirm_name prerequisite. It also explains the preview-vs-apply split, though it does not name alternative tools or explicitly say when not to use this deletion path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools