Skip to main content
Glama
Sign In
Ads MCP for Snapchat

Ads MCP for Snapchat

by Usame794
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

snap_report

Read-only

Generates a read-only Snapchat performance table for a campaign or ad squad, broken down by ad squad or ad, showing spend, purchases, ROAS, CPA, swipe rate, and frequency for a specified time range.

Instructions

Performance table for a campaign or ad squad broken down by ad squad or ad: spend, purchases, ROAS, CPA, swipe rate and frequency (read-only). Times must fall on the hour, with offset.

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>",
      "breakdown": "<breakdown>",
      "start_time": "<start_time>",
      "end_time": "<end_time>"
    },
    "name": "snap_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
entityYes
end_timeYes
breakdownYes
start_timeYese.g. 2026-10-19T00:00:00+00:00
view_attribution_windowNoPin the view attribution window; default is the account's setting
swipe_up_attribution_windowNoPin the swipe attribution window; default is the account's setting

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.1

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so 'read-only' in the description is redundant. The description does add one genuine behavioral constraint beyond the annotations: start and end times must land on the hour and include an offset, which is a real failure mode an agent would otherwise hit. It says nothing about result size, row limits, pagination, or empty-result behavior for a report that could return many rows.

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?

A single dense sentence plus one constraint sentence, with the core purpose and metric list front-loaded. Nothing is padding. The time-format rule is appended rather than given its own line, but it is still clearly separated and easy to parse.

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

Completeness3/5

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

With no output schema, the description usefully enumerates the returned metrics, which is the right compensation. But for a 7-parameter, 5-required report tool it leaves real gaps: no note on result shape or volume, no explanation of `id`, and no routing against the many sibling report tools. It is adequate to call the tool, but not to call it confidently or to choose it over alternatives.

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 description coverage is only 43% across 7 parameters, so the description should compensate more than it does. It does clarify the two enum dimensions semantically (entity = campaign or ad squad, breakdown = ad squad or ad), and it constrains the time parameters, which helps. However, it says nothing about the required `id` parameter or the two attribution-window parameters beyond what the schema already provides.

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 states a concrete resource (performance table) scoped to a campaign or ad squad, with an explicit metric list (spend, purchases, ROAS, CPA, swipe rate, frequency) and breakdown dimension. That is far more specific than the name alone. It stops short of differentiating itself from the many sibling report tools (snap_report_daily, snap_report_hourly, snap_report_compare, snap_report_audience), so the agent gets no signal on why to pick this report over those.

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

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance and no named alternative, despite a dense cluster of sibling report tools that an agent could easily confuse with this one. The only constraint given ('Times must fall on the hour, with offset') is a call-validity rule, not usage routing. The agent must infer the selection criteria from the tool name and schema enums.

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