Skip to main content
Glama
Sign In
Ads MCP for Snapchat

Ads MCP for Snapchat

by Usame794
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

snap_set_status_bulk

Destructive

Enable or pause up to 20 Snapchat campaigns, ad squads, or ads in one batch; preview each status change before confirming and stop at the first failure.

Instructions

Enable (ACTIVE) or pause (PAUSED) up to 20 campaigns, ad squads or ads in one go. Previews unless confirm=true: shows each change, skips ones already in that state, warns when a parent is paused, and for ACTIVE shows the daily budget that would really start delivering (refused above the configured limits). Stops at the first failure and reports exactly what changed. Never deletes. 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>",
      "ids": "<ids>",
      "status": "<status>"
    },
    "name": "snap_set_status_bulk"
  }
}

Input Schema

NameRequiredDescriptionDefault
idsYes
entityYes
statusYes
confirmNofalse = preview only (nothing sent). true = apply; needs approval_token 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.3/5.0
Behavior5/5

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

Beyond the annotations, it discloses partial-failure semantics ('stops at the first failure'), skip-if-already-in-state behavior, pre-application validation via preview, the two-step token handshake, and an explicit 'never deletes' safety statement. The 'never deletes' claim is not an annotation contradiction: destructiveHint=true is consistent with pausing live delivery, and the description clarifies the actual blast radius rather than conflicting with it.

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

Conciseness4/5

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

Dense but front-loaded — purpose first, then preview semantics, then the two-step procedure. Every sentence carries operational information, though the budget/parent-pause sentence is a packed run-on that could be split for faster scanning.

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

Completeness5/5

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

For a bulk mutation with no output schema, the description covers the preview payload, what the apply step reports, partial-application behavior, refusals, and no-op skipping. An agent can execute the full two-call workflow without further guesswork; only token expiry/naming is unaddressed, which is minor.

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

Parameters4/5

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

With only 40% schema description coverage, the description carries real weight: it maps status to ACTIVE/PAUSED outcomes, ties ids to the 20-item cap, and defines the confirm/approval_token pairing as a repeat-the-same-arguments flow. The entity enum and the failure behavior of the token (wrong or stale request) are left thin, so it doesn't fully compensate for the coverage gap.

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

Purpose4/5

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

The description opens with specific verbs and resources: enable (ACTIVE) or pause (PAUSED) campaigns, ad squads or ads, bounded to 'up to 20 ... in one go', which makes the bulk scope obvious. It stops short of naming the single-entity sibling (snap_set_status) as the alternative for one-off changes, so routing between the two is inferred rather than stated.

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 a concrete operating context: preview by default, apply only with confirm=true plus the approval_token from that exact preview, and it explains what the preview surfaces (skipped no-ops, paused-parent warnings, effective daily budget, refusal above limits). No explicit when-not-to-use condition or named alternative is provided, which keeps it below a 5.

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