Skip to main content
Glama

Send a studio creative or copy into a running ad

send_to_ad
Idempotent

Put a studio ad (all its sizes: the creative ids of one ad) or ad texts written by Taseli's studio into a RUNNING ad, as one proposal the owner approves in Taseli (nothing changes before that). Without kind, lists where it fits: Meta ad sets (a new ad with the ad set's own link and button), Performance Max asset groups (pictures, videos and headlines/long headlines/descriptions added as assets, within the group's room), Demand Gen ad groups (a new image or video ad copying the group's logo, name, button and page), TikTok ad groups (a new ad next to the busiest one, created off; once TikTok approves it the owner is asked to turn it on, then it's compared for a week), and, with copy, live search ads (new lines into free slots, then over weak ones; never a pinned line). Read-only accounts are never sent to. Google checks every change first (validate only).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "send_to_ad"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoWhere, as the list says; omit to list the places.
languageNoAnswer language.
headlinesNoGoogle headlines (≤ 30).
target_idNoThe place's id, as the list says.
account_idNoThe Taseli ad account id, as the list says.
meta_wordsNometa_ad: keep the ad set's live words (default), or new words: primary_texts / headlines / descriptions when given (checked against Meta's limits), else written now for the picture. Several options go as Meta's multiple text options when the ad set takes them (Meta checks first), else one. A carousel uses its own words unless keep.
tiktok_textNoTikTok ad text (12-100, no links, @ or #); omit to keep the source ad's.
creative_idsNoThe library creatives of ONE ad (its sizes, ≤ 8), or every card of one carousel (both shapes).
descriptionsNoGoogle descriptions (≤ 90).
primary_textsNometa_ad with meta_words new: primary texts (≤ 125); headlines (≤ 40) and descriptions (≤ 30) then count as Meta's.
long_headlinesNoPerformance Max long headlines (≤ 90).

Output Schema

NameRequiredDescriptionDefault
noteNoA plain note instead of data (nothing connected yet, not available here).
errorNoWhy nothing was done, as a short code.
truncatedNo
truncatedNoteNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: nothing is mutated before the owner approves a proposal, Google validates every change first, and TikTok ads are created off then compared for a week. These are exactly the consequences an agent needs to know before calling a non-read-only, open-world tool, and none are derivable from the annotation flags.

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

Conciseness3/5

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

The core constraint (proposal, nothing changes until approval) is correctly front-loaded, but the body is a single run-on sentence with a nested six-item parenthetical full of sub-clauses. It is dense rather than bloated, yet the structure makes the per-destination behavior hard to parse in one pass.

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 an 11-parameter, six-mode, open-world tool, the description covers each destination's behavior, the listing fallback, and the approval gate. With an output schema present and detailed parameter descriptions, no critical decision-relevant information appears missing.

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 100% and the parameter descriptions are already detailed, so the baseline of 3 applies. The description does add the semantic link that supplying copy routes the request to live search ads, but it adds no format, default, or interaction detail beyond what the schema already carries.

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?

States a concrete verb and resource: placing a studio ad's creative ids, or studio-written ad texts, into a RUNNING ad as a proposal. The enumerated destinations (Meta ad sets, PMax asset groups, Demand Gen ad groups, TikTok ad groups, live RSAs) make the scope unmistakable. It loses a point because it never distinguishes itself from likely-overlapping siblings such as place_creatives or propose_change.

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

Usage Guidelines3/5

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

Gives a useful discovery path: omitting `kind` lists where the creative fits, and read-only accounts are excluded, which tells the agent when the tool will refuse. However, it offers no explicit guidance on when to choose this over place_creatives or propose_change, and no prerequisites are stated beyond the read-only note.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources