Ads MCP for Snapchat

Overview Schema Source Related Servers Discussions Admin

snap_create_lookalike

Creates a Snapchat lookalike audience from a first-party customer list seed segment. Returns a preview with an approval token first, then applies the audience on confirmation; nothing is delivered.

Instructions

Create a lookalike audience from a first-party (customer list) seed segment. Creates an audience only, nothing is delivered. 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": {
      "seed_segment_id": "<seed_segment_id>",
      "name": "<name>"
    },
    "name": "snap_create_lookalike"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`type`	No		BALANCE
`confirm`	No	false = preview only (nothing sent). true = apply; needs approval_token from the preview.
`countries`	No	2-letter codes; defaults to SNAP_DEFAULT_COUNTRY
`approval_token`	No	The approval_token returned by the preview of this exact request. Required with confirm=true.
`retention_days`	No
`seed_segment_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.9.1Nov 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare it as a non-destructive, non-idempotent open-world write. The description adds the crucial behavior the annotations cannot: nothing is delivered, the default call is a no-op preview, and applying requires replaying identical arguments with a token from the preview. This is exactly the safety-critical context an agent needs before mutating state.

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

Conciseness5/5

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

Four short sentences, front-loaded with what is created and what is not, then the two-step mechanics. No filler; nearly every clause conveys a fact the agent would otherwise have to guess.

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 7-parameter mutation with no output schema, the definition covers the effect, the default, and the approval mechanism fully. It could say more about what the preview returns (e.g. estimated audience size) and how the lookalike type choice affects results, but nothing essential to correct invocation is missing.

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 43%, so the description must compensate, and it does for the two highest-risk parameters: confirm is explained as preview-vs-apply and approval_token is explained as the value returned by the preview of that exact request. It says nothing about the type enum (BALANCE/SIMILARITY/REACH), countries, or retention_days, leaving that to the schema.

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?

States a specific verb and resource ('Create a lookalike audience') and pins the seed source as a first-party customer-list segment, which distinguishes it from pixel-based audience creation among the siblings. It also immediately scopes the effect ('Creates an audience only, nothing is delivered'), so the agent knows what this tool does not do.

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 clear operational guidance: preview is the default, applying requires the two-step confirm=true plus approval_token flow. It does not name sibling alternatives (e.g. pixel audience creation) explicitly, so routing guidance is implied by the seed-type constraint rather than enumerated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server