Skip to main content
Glama
Sign In
Ads MCP for Snapchat

Ads MCP for Snapchat

by Usame794
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

snap_upload_customer_list

Creates a Snapchat customer-list audience from a local CSV of emails or phone numbers, hashing values locally and requiring preview-token confirmation before upload.

Instructions

Create a customer-list audience from a local CSV of emails or phone numbers. Values are normalised and SHA-256 hashed on this machine; only hashes are uploaded and no raw value is ever shown or logged. Previews (counts only) unless confirm=true. Local phone numbers get default_country_code (or SNAP_DEFAULT_PHONE_CODE); without either they are counted as invalid. 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": {
      "file_path": "<file_path>",
      "kind": "<kind>",
      "name": "<name>"
    },
    "name": "snap_upload_customer_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYes
nameYesAudience name
columnNoHeader of the column to use; found automatically when omitted
confirmNofalse = preview only (nothing sent). true = apply; needs approval_token from the preview.
file_pathYesAbsolute path to a .csv with a header row
approval_tokenNoThe approval_token returned by the preview of this exact request. Required with confirm=true.
default_country_codeNoCountry code (digits, no +) for local numbers; defaults to SNAP_DEFAULT_PHONE_CODE. Without one, local numbers are counted as invalid.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.1

TDQS

A4.5/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing that values are normalized and SHA-256 hashed locally, only hashes are uploaded, and raw values are never shown or logged – meaningful privacy behavior an agent could not infer from readOnlyHint/destructiveHint. It also explains that local phone numbers without a country code are counted as invalid rather than failing, which is real behavioral context. It stops short of describing error cases (e.g. malformed CSV, missing header) or what a preview response contains beyond counts.

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 sentences, each carrying distinct information – purpose, hashing guarantee, preview gate, phone-code fallback, and the two-step protocol – with the critical hashing and preview facts front-loaded. No filler or restatement of the tool name.

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

Completeness5/5

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

For a 7-parameter write tool with no output schema, it covers the privacy model, the preview/approval workflow, the phone-code fallback and its invalid-number consequence, and what the preview returns (counts plus approval_token). An agent has enough to call it correctly on the first attempt without extra discovery.

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?

With 86% schema coverage the baseline is 3, but the description adds meaning the schema cannot: default_country_code falls back to the SNAP_DEFAULT_PHONE_CODE environment variable, and approval_token must come from a preview of this exact request and be paired with identical arguments. Those are cross-parameter and environment semantics that materially change how the agent fills the fields.

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?

Opens with a specific verb and resource: 'Create a customer-list audience from a local CSV of emails or phone numbers.' Both the output artifact (audience) and the input format (CSV of emails/phones) are named, so an agent can tell this apart from generic upload or audience-listing tools at a glance.

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?

Explicitly describes the two-step flow: confirm=false returns a preview and approval_token, and applying requires repeating the same arguments with confirm=true plus that token. That is clear when-to-use-which guidance for the two modes, though it doesn't name any sibling tool or state when a different audience-creation path should be preferred.

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