Skip to main content
Glama
jshorwitz

synter-mcp-server

by jshorwitz
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

sync_audience

Destructive

Upload an audience to multiple ad platforms (Google, Meta, LinkedIn, etc.) using hashed emails, phones, mobile IDs, company domains, or a CSV URL.

Instructions

Upload an audience to an ad platform (Google, Meta, LinkedIn, Microsoft, Reddit, TikTok, X). Accepts inline hashed identifiers (hashed_emails, hashed_phones), raw mobile_ids (IDFA/GAID), company_domains, a public csv_url, or *_artifact_id references staged via stage_audience_artifact. Costs 10 credits on success.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
csv_urlNoPublic CSV URL with audience identifiers. Alternative to inline params / artifact ids.
platformYesAd platform to upload to.
account_idNoPlatform ad account id. Optional — defaults to the user's primary account on that platform.
mobile_idsNoComma-separated raw mobile advertising IDs (IDFA / GAID, uppercase UUID). Meta and TikTok only. NOT hashed.
audience_nameNoName for the audience as it should appear in the platform's UI.
hashed_emailsNoComma-separated SHA-256 hashed emails (lowercase hex). For small batches; use hashed_emails_artifact_id for >500.
hashed_phonesNoComma-separated SHA-256 hashed phones (E.164 format pre-hash). For small batches.
i_have_consentNoConfirm the customer has lawful basis (GDPR Art. 6) and required consent under CCPA / Meta Custom Audience Terms / Google Customer Match Policy for every identifier in this audience. Soft-launch: omitting this flag logs a warning until 2026-05-21, after which the upload is rejected with PII_CONSENT_REQUIRED. Pass true only if your customer has obtained the required consents.
company_domainsNoComma-separated company domains for B2B account targeting (Google + LinkedIn).
customer_file_sourceNoMeta only: USER_PROVIDED_ONLY (default), PARTNER_PROVIDED_ONLY, or BOTH_USER_AND_PARTNER_PROVIDED.
mobile_ids_artifact_idNoArtifact id for raw mobile ids. Meta only.
hashed_emails_artifact_idNoArtifact id from stage_audience_artifact for SHA-256 hashed emails.
hashed_phones_artifact_idNoArtifact id from stage_audience_artifact for SHA-256 hashed phones. Meta + most platforms; not supported by Google's customer match script today.

Tool Definition Quality

A3.8/5.0
Behavior2/5

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

Annotations already mark it as destructive, but the description adds only the credit cost. It does not explain what happens to existing audiences (overwrite, duplicate), rate limits, permissions, or idempotency. For a destructive tool, more behavioral context is expected.

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?

The description is concise, using a single paragraph that covers key points: action, platforms, input methods, and cost. It could be slightly more structured (e.g., bullet points), but it is not verbose.

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?

Given the high parameter count (13) and complexity, the description covers input methods and cost but omits crucial details like return values, error handling, and behavior on existing audiences. Without an output schema, this is a notable gap.

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 provides 100% coverage, but the description adds meaning by specifying batch size limits ('hashed_emails_artifact_id for >500'), explaining the 'i_have_consent' parameter with soft-launch details, and listing which platforms support certain identifiers. This goes beyond the schema definitions.

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?

The description clearly states the action ('Upload an audience') and the resource ('to an ad platform'), listing all supported platforms (Google, Meta, LinkedIn, etc.). It distinguishes from siblings like 'stage_audience_artifact' and 'manage_audience' by focusing on the upload/sync action.

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?

The description provides guidance on when to use inline identifiers vs artifact IDs ('use hashed_emails_artifact_id for >500'), and mentions the credit cost. However, it does not explicitly state when not to use this tool or compare it to alternatives like 'manage_audience'.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jshorwitz/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server