Skip to main content
Glama
Sign In
Ads MCP for Snapchat

Ads MCP for Snapchat

by Usame794
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

snap_set_ad_schedule

Set which hours and days a Snapchat ad squad runs on lifetime budgets, or schedule every hour, and preview changes before applying with approval.

Instructions

Choose which hours of which days an ad squad's ads run (hours 0-23 in each viewer's local time), or run every hour. Snap allows this only on LIFETIME-budget ad squads, so it is refused on daily-budget ones. A narrow schedule lowers delivery. Undo works when a schedule existed before. 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

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": {
      "adsquad_id": "<adsquad_id>"
    },
    "name": "snap_set_ad_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
alwaysNotrue = every hour of every day
confirmNofalse = preview only (nothing sent). true = apply; needs approval_token from the preview.
scheduleNoe.g. {"friday": [18,19,20,21], "saturday": [18,19,20,21]}
adsquad_idYes
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.2/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true) by disclosing the budget-type gating and refusal case, the delivery impact of a narrow schedule, the reversibility condition for undo, and the mandatory two-step preview/approval_token protocol. The non-destructive hint is consistent with 'previews unless confirm=true', and the non-idempotent hint is reinforced by explaining the token must match the exact previewed request.

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?

Front-loads the core action, then the constraint, then the safety protocol, with essentially no filler. The clipped phrase 'Undo works when a schedule existed before' is slightly cryptic since no undo parameter exists, which costs a bit of clarity.

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 5-parameter mutation tool with a nested schedule object and no output schema, the description covers the critical operational facts an agent needs: budget-type precondition, preview/confirm handshake, and delivery consequences. Only the always-vs-schedule precedence and the return shape of the preview are left to inference.

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?

Adds meaning beyond the 80%-covered schema by clarifying that hours are interpreted in each viewer's local time, that 'always' means every hour of every day, and by restating the confirm/approval_token contract that ties the two calls together. The interaction between 'always' and 'schedule' (mutually exclusive or not) is still unstated.

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?

States a concrete verb and resource: choose which hours of which days an ad squad's ads run, with local-time hours 0-23 or an always-on mode. It clearly describes the operation, but it never names or distinguishes itself from the nearby snap_set_schedule / snap_bulk_set_schedule siblings, leaving the agent to guess at scope differences.

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?

Gives real selection context: only valid on LIFETIME-budget ad squads and refused on daily-budget ones, plus the caveat that undo only works when a schedule previously existed. It does not explicitly say when to prefer this over the bulk or campaign-level schedule tools, which is the main remaining gap.

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