Provides tools for managing and analyzing Snapchat Ads campaigns, including listing accounts, campaigns, ad squads, and ads; retrieving performance stats (ROAS, CPA, CTR, etc.); pausing/activating entities; updating campaign budgets; and managing creatives.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Snapchat Ads MCP Server Give me a 7-day performance report for my top campaign"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A free, open-source Model Context Protocol (MCP) server that connects Claude AI directly to your Snapchat Ads account — enabling live campaign analysis and real actions without leaving your chat.
Capability | Tools |
Analyze | Account report, campaign stats, ad squad breakdown, creative performance |
Act | Pause/activate campaigns & ad squads, update budgets, rename campaigns |
Metrics | ROAS, CPA, CTR, eCPM, swipe-up rate, video views, avg screen time |
No CSV exports. No manual copy-paste. Just ask Claude in plain language.
Related MCP server: Google Ads MCP
"Give me a performance report for last 7 days"
"Pause all underperforming ad squads"
"What's my ROAS across all active campaigns?"
"Update daily budget for campaign X to $100"Python 3.10+
Snapchat Business Account
Snapchat Marketing API credentials (free — see setup below)
pip install snapchat-ads-mcpOr run directly without installing (requires uv):
uvx snapchat-ads-mcpClaude Desktop config with PyPI install:
{
"mcpServers": {
"snapchat-ads": {
"command": "uvx",
"args": ["snapchat-ads-mcp"],
"env": {
"SNAPCHAT_CLIENT_ID": "your_client_id",
"SNAPCHAT_CLIENT_SECRET": "your_client_secret"
}
}
}
}git clone https://github.com/saadsh0/snapchat-ads-mcp
cd snapchat-ads-mcp
pip install -r requirements.txtgit clone https://github.com/saadsh0/snapchat-ads-mcp
cd snapchat-ads-mcp
pip install -r requirements.txtGo to business.snapchat.com
Navigate to Business Details → OAuth Apps → New App
Set redirect URI to https://example.com
Copy your Client ID and Client Secret
⚠️ Use Business Manager to create the app — NOT the Developer Portal
export SNAPCHAT_CLIENT_ID=your_client_id
export SNAPCHAT_CLIENT_SECRET=your_client_secretOr create a .env file (see .env.example).
python auth_setup.pyThis opens Snapchat in your browser → you click Allow → you paste the redirect URL → your org is auto-detected and locked into config → tokens saved. Never needed again.
Add this to your claude_desktop_config.json:
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"snapchat-ads": {
"command": "python3",
"args": ["/full/path/to/snapchat-ads-mcp/server.py"],
"env": {
"SNAPCHAT_CLIENT_ID": "your_client_id",
"SNAPCHAT_CLIENT_SECRET": "your_client_secret"
}
}
}
}Restart Claude Desktop. Done.
Tool | Description |
| List all ad accounts — start here |
| All campaigns with budget & status |
| Ad squads with targeting & bid info |
| Individual ads |
| Stats for any campaign / ad squad / ad |
| Full account-level summary |
| Pause or activate any entity |
| Change daily budget or lifetime cap |
| List creative assets |
List all my Snapchat ad accounts
Give me a 7-day performance report for account [ID]
Which campaigns have the highest CTR this week?
Pause the Indonesia ad squad — CTR is too low
Update campaign [ID] daily budget to $150
Compare performance across all active ad squads
Rename campaign [ID] to [new name]Snapchat API uses micro-dollars: $1 = 1,000,000
USD | Micro-dollars |
$10 | 10,000,000 |
$50 | 50,000,000 |
$100 | 100,000,000 |
See AGENT_FLOWS.md for connecting this MCP to Antigravity agents for automated reporting and optimization workflows.
Each client gets their own isolated config with their own tokens and org ID.
python auth_setup.py --client skyline
python auth_setup.py --client fantasticEach run saves to with org ID locked automatically.
{
mcpServers: {
snapchat-skyline: {
command: python3,
args: [/full/path/to/server.py],
env: {
SNAPCHAT_CLIENT_ID: your_app_id,
SNAPCHAT_CLIENT_SECRET: your_secret,
SNAPCHAT_CONFIG_FILE: /full/path/to/clients/skyline/config.json
}
},
snapchat-fantastic: {
command: python3,
args: [/full/path/to/server.py],
env: {
SNAPCHAT_CLIENT_ID: your_app_id,
SNAPCHAT_CLIENT_SECRET: your_secret,
SNAPCHAT_CONFIG_FILE: /full/path/to/clients/fantastic/config.json
}
}
}
}✅ One OAuth app (your Sigma Digital credentials) works for all clients. Each client is fully isolated — wrong org access is blocked at the server level.
You'll see and as separate tool sets. Tell Claude which client to use and it only touches that org's data.
"CLIENT_ID not set" → Set env variables before running
"No tokens found" → Run python auth_setup.py
"Error 401" → Token expired, run python auth_setup.py again
"Error 403" → Check Snapchat Business account has Marketing API access
Tools not showing in Claude → Verify path in config and restart Claude Desktop
Sigma Digital — Performance Marketing & AI Automation Agency
MIT — free to use, modify, and distribute.
Full account-level performance report with per-campaign breakdown. Uses breakdown=campaign to fetch all campaign stats in 2 API calls total (1 for campaign names, 1 bulk stats call) — same efficiency as Meta Ads API. Falls back to concurrent per-campaign calls if breakdown endpoint returns an error. Results cached per account + date range for 5 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm read-only and non-destructive behavior. The description adds valuable behavioral details: uses 2 API calls, falls back to concurrent calls on error, and caches results for 5 minutes. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding distinct value: purpose, efficiency, fallback, caching. Front-loaded with the core function. No redundant or fluff sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, efficiency, fallback, and caching. With output schema present and good parameter descriptions, the description is nearly complete. Could mention comparison to siblings for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has detailed descriptions for each property within StatsInput, so the schema carries the burden. The description does not add parameter-level meaning beyond what the schema provides, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full account-level performance report with per-campaign breakdown', using a specific verb ('get') and resource ('account report'). It distinguishes from sibling tools like snapchat_get_performance_stats which target individual entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for broad account reporting but does not explicitly mention when to use this tool versus alternatives like snapchat_get_performance_stats. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Snapchat Ad Accounts linked to this config. When an org_id is saved in config, only that org's accounts are returned — preventing cross-client data access in agency setups.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context about org-level filtering and cross-client isolation, which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise, front-loaded with the main action, and every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, rich annotations, and an output schema, the description fully covers the tool's behavior, including critical filtering logic. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description does not need to explain parameters, so a baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ad accounts and explains the filtering behavior based on org_id in config, distinguishing it from siblings that focus on specific entities or reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing ad accounts tied to the config's org. It does not explicitly exclude alternatives, but the context of sibling tools makes the purpose clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Ads in an account. Excludes DELETED. Results cached for 5 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint:true and destructiveHint:false. The description adds useful behavioral traits: excludes DELETED ads and results cached for 5 minutes, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no wasted words. Perfectly concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and the tool's simplicity (one parameter, read-only), the description adequately covers filtering (excludes DELETED) and caching behavior, making it complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter already described in the input schema as 'Snapchat Ad Account ID (UUID)', the description does not add further parameter details. Schema description coverage is 0% per context, but the schema itself has a description, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'Ads in an account', differentiating it from sibling tools that list other entities like ad accounts, campaigns, or ad squads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (to list all ads in an account) but does not explicitly state when not to use or suggest alternatives, though siblings provide context for other needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Ad Squads for an account or specific campaign. Excludes DELETED. Results cached for 5 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by disclosing exclusion of DELETED records and caching behavior, which are beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences contain all key information without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with an output schema present, the description adequately covers purpose, exclusions, and caching. However, it does not mention pagination or result ordering, which could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on parameter meanings or usage. The schema itself has descriptions for the parameters, but the description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all Ad Squads for an account or specific campaign,' using a specific verb and resource. It distinguishes from sibling tools like snapchat_get_ads and snapchat_get_campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by noting that DELETED squads are excluded and results are cached for 5 minutes, but does not explicitly state when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all campaigns for a Snapchat Ad Account with status and budget info. Returns ACTIVE, PAUSED, and COMPLETED campaigns — excludes DELETED only. Results cached for 5 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. The description adds that it returns only active, paused, completed campaigns (excluding deleted) and that results are cached for 5 minutes, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences covering purpose, return details, and caching. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists. Description adequately covers the main behavior (list, statuses, caching) but could mention pagination or ordering if applicable. Minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the 'ad_account_id' parameter beyond what the schema provides. No additional meaning or usage tips are given, despite low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all campaigns for a Snapchat Ad Account with status and budget info.' Specific verb 'list' and resource 'campaigns' with scope. Also distinguishes that it excludes DELETED campaigns, making it distinct from other sibling tools like snapchat_get_ads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like snapchat_get_ad_squads or snapchat_get_performance_stats. The description does not mention when not to use it or provide context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all creatives in your ad account. Results cached for 5 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and destructiveHint. The description adds the caching behavior (5-minute cache), which is beyond what annotations provide. No contradictions; the description aligns with a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. Every word is necessary and front-loaded: the action and the important caching note. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers the essential action and caching behavior. A minor enhancement could mention that it returns all creatives for the account, but it is already fairly complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the required parameter ad_account_id. Although the input schema has a description for it, the context indicates schema description coverage is 0%, meaning the description must compensate. Failing to mention the parameter leaves the agent without guidance on what to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all creatives in the ad account. It uses a specific verb ('List') and resource ('creatives'), and it naturally distinguishes from sibling tools like snapchat_get_ads or snapchat_get_campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case (listing creatives) and adds the caching detail, which informs the agent about data freshness. However, it does not explicitly mention when not to use this tool or suggest alternatives, though the sibling tools cover different entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get performance statistics for a campaign, ad squad, or ad. Returns: impressions, swipe-ups, spend, CTR, eCPM, video views, conversions, ROAS. Results cached per entity + date range for 5 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and non-destructive behavior. The description adds caching details (5-minute cache per entity and date range), which is valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loaded with the main purpose, and every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, annotations, and output schema, the description sufficiently covers return values and caching. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add parameter information; the schema already provides basic descriptions for each parameter. With high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves performance statistics for campaigns, ad squads, or ads, and lists key metrics. It clearly distinguishes from sibling tools focused on listing entities or account reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description impies usage for performance metrics but does not explicitly state when to use this tool over alternatives, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the daily budget or lifetime spend cap of a campaign. $1 = 1,000,000 micro-dollars. Example: $50/day = 50000000. Automatically clears cached data for the account after the update.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only and not destructive. The description adds that it 'automatically clears cached data', a behavioral side effect not captured by annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the core action, second provides a conversion example and side effect. No superfluous words, efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described. The description covers the primary action and a key side effect. However, it does not clarify whether both daily_budget_micro and lifetime_spend_cap_micro can be updated simultaneously.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for each parameter (e.g., micro-dollar conversion). The description briefly reiterates the conversion example but adds no new semantic meaning beyond what the schema conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'daily budget or lifetime spend cap of a campaign', distinguishing this tool from sibling tools like snapchat_update_status that update campaign status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a conversion example for micro-dollars, aiding correct usage. However, it does not explicitly state when to use this tool versus alternatives (e.g., update_status), nor does it mention constraints like setting at least one budget field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause or activate a campaign, ad squad, or ad. Automatically clears cached data for the account after the update.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a side effect (clearing cached data) beyond annotations, which already indicate idempotency but not destructiveness. This provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states core purpose, second adds important side effect. No redundant information, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for an update tool with good schema descriptions and an output schema. Lacks explicit mention of required parameters but schema covers them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has detailed descriptions for all sub-properties, so the description adds no extra parameter meaning. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Pause or activate' and the resource types 'campaign, ad squad, or ad', distinguishing it from sibling read tools and the budget update tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for status updates but does not explicitly state when to use or not use this tool, nor does it mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.4snapchat_get_account_reportsnapchat_get_ad_accountssnapchat_get_ad_squadssnapchat_get_adssnapchat_get_campaignssnapchat_get_creativessnapchat_get_performance_statssnapchat_update_campaign_budgetsnapchat_update_statusScored across 9 tools
Each tool targets a distinct entity or operation (accounts, campaigns, ad squads, ads, creatives, performance stats, budget update, status update, and account report). No two tools have overlapping purposes, making selection unambiguous.
All tools follow a consistent 'snapchat_{verb}_{noun}' pattern with snake_case. Verbs are either 'get' for retrieval or 'update' for modification, ensuring predictability.
With 9 tools, the set is well-scoped for an ads platform. It covers key entities and operations without being overwhelming or too sparse.
The tool set provides read operations for all major entities and updates for budget and status, but lacks create/delete functionality for campaigns, ad squads, ads, and creatives, which are common advertising operations.
Ask Claude about your ads: Meta, Google, TikTok, LinkedIn, GA4 & Shopify. No AI credits.
Run Google Ads and Meta Ads from ChatGPT or Claude: audit wasted spend, create and manage campaigns.
Run Google, Meta, Microsoft, TikTok and LinkedIn Ads from Claude or ChatGPT. Writes need approval.
Create, launch, and manage Meta + Google ads from Claude and ChatGPT.
