Skip to main content
Glama
Sign In
Ads MCP for Snapchat

Ads MCP for Snapchat

by Usame794
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

snap_undo

Destructive

Revert previously applied ad changes such as budget, bid, status, targeting, schedule, or rename using the change log, with a preview and approval step before applying.

Instructions

Revert one of the changes this server applied (budget, bid, status, targeting, schedule, rename) using the change log. An undo is checked like any other change: raising a budget or bid back up stays within the configured limits, and re-enabling shows and limits what would start delivering. Refuses if the field was changed again since, unless force=true. Not for creates, claims or copies. Previews 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

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "snap_undo"
  }
}

Input Schema

NameRequiredDescriptionDefault
forceNo
confirmNofalse = preview only (nothing sent). true = apply; needs approval_token from the preview.
n_from_lastNo1 = the most recent undoable change
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.5/5.0
Behavior5/5

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

Annotations only say destructive and open-world; the description goes much further, disclosing the two-step preview/approval_token flow, that an undo is re-validated against budget/bid limits and delivery constraints, and that it refuses on intervening field changes unless force=true. This is behavior an agent could not infer from the annotations or schema.

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?

Information is front-loaded: what it does, validation behavior, refusal conditions, scope limits, then the confirm workflow. Slight redundancy between 'Previews unless confirm=true' and the following 'Two steps' sentence costs a point, but no sentence is filler.

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 mutation with no output schema, the definition covers safety, preconditions, and the apply workflow well. It leaves open what an apply returns and how far back n_from_last can reach, both minor given the 4-parameter surface.

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?

Schema coverage is 75%, so the baseline would be 3; the description earns above that by explaining the force escape hatch and the confirm/approval_token handshake semantics. It doesn't mention n_from_last in prose, leaving that parameter to the schema's own description.

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: 'Revert one of the changes this server applied (budget, bid, status, targeting, schedule, rename) using the change log.' It also delimits scope negatively with 'Not for creates, claims or copies,' so an agent can distinguish undo from create/clone/claim siblings without opening a schema.

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?

Usage context is clear: revert a previously applied change, refuses if the field was changed again unless force=true, and previews unless confirm=true. Exclusions are explicit. It does not name a sibling (e.g. snap_change_log) for discovering which n_from_last index to target, so alternatives are implied rather than stated.

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