Skip to main content
Glama
kLOsk

AdLoop: Google Ads, Reddit Ads & GA4

by kLOsk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Draft a responsive search ad

draft_responsive_search_ad

Preview a responsive search ad with headlines, descriptions, and a reachable final URL before creating it. The ad is created paused; confirm the plan ID to apply.

Instructions

Draft a Responsive Search Ad — returns a PREVIEW, does NOT create the ad.

The preview shows exactly what will be created; confirm_and_apply executes the returned plan_id. The ad is created PAUSED. final_url is checked for reachability first and an unreachable URL is refused. Several headlines may pin to the same position (Google rotates them there) as long as every position stays fillable, by an asset pinned to it or by a distinct unpinned one. Mixed plain-string and dict entries are allowed within a single call (e.g. brand pinned to HEADLINE_1, the rest unpinned). Warnings note fewer than 8 headlines or 3 descriptions.

Google Ads API: https://developers.google.com/google-ads/api/docs/start

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
path1NoOptional first display-URL path segment (Google allows up to 15 chars).
path2NoOptional second display-URL path segment (Google allows up to 15 chars).
final_urlYesLanding page URL the ad links to; must be reachable.
headlinesYes3-15 headlines, max 30 chars each. Each entry is a plain string (unpinned) or {"text": "...", "pinned_field": "HEADLINE_1"}; valid pins are HEADLINE_1, HEADLINE_2, HEADLINE_3. Keyword or location insertion such as {KeyWord:Drain Cleaning} counts as its default text, which is required.
ad_group_idYesNumeric ID of the ad group that gets the ad.
customer_idNoGoogle Ads customer ID (digits, e.g. "1234567890"). Empty uses the configured default account.
descriptionsYes2-4 descriptions, max 90 chars each. Each entry is a plain string (unpinned) or {"text": "...", "pinned_field": "DESCRIPTION_1"}; valid pins are DESCRIPTION_1, DESCRIPTION_2. Insertion tags count as their default text, as for headlines.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.29.2
    • changedInput schema / properties / descriptions / description
      Previous value: -"2-4 descriptions, max 90 chars each. Each entry is a plain\nstring (unpinned) or {\"text\": \"...\", \"pinned_field\": \"DESCRIPTION_1\"};\nvalid pins are DESCRIPTION_1, DESCRIPTION_2."New value: +"2-4 descriptions, max 90 chars each. Each entry is a plain\nstring (unpinned) or {\"text\": \"...\", \"pinned_field\": \"DESCRIPTION_1\"};\nvalid pins are DESCRIPTION_1, DESCRIPTION_2. Insertion tags count\nas their default text, as for headlines."
    • changedInput schema / properties / headlines / description
      Previous value: -"3-15 headlines, max 30 chars each. Each entry is a plain\nstring (unpinned) or {\"text\": \"...\", \"pinned_field\": \"HEADLINE_1\"};\nvalid pins are HEADLINE_1, HEADLINE_2, HEADLINE_3."New value: +"3-15 headlines, max 30 chars each. Each entry is a plain\nstring (unpinned) or {\"text\": \"...\", \"pinned_field\": \"HEADLINE_1\"};\nvalid pins are HEADLINE_1, HEADLINE_2, HEADLINE_3. Keyword or\nlocation insertion such as {KeyWord:Drain Cleaning} counts as its\ndefault text, which is required."
  2. Changed7 schema fields changedv0.27.1
    • addedInput schema / properties / ad_group_id / description
      Added value: +"Numeric ID of the ad group that gets the ad."
    • addedInput schema / properties / customer_id / description
      Added value: +"Google Ads customer ID (digits, e.g. \"1234567890\"). Empty\nuses the configured default account."
    • addedInput schema / properties / descriptions / description
      Added value: +"2-4 descriptions, max 90 chars each. Each entry is a plain\nstring (unpinned) or {\"text\": \"...\", \"pinned_field\": \"DESCRIPTION_1\"};\nvalid pins are DESCRIPTION_1, DESCRIPTION_2."
    • addedInput schema / properties / final_url / description
      Added value: +"Landing page URL the ad links to; must be reachable."
    • addedInput schema / properties / headlines / description
      Added value: +"3-15 headlines, max 30 chars each. Each entry is a plain\nstring (unpinned) or {\"text\": \"...\", \"pinned_field\": \"HEADLINE_1\"};\nvalid pins are HEADLINE_1, HEADLINE_2, HEADLINE_3."
    • addedInput schema / properties / path1 / description
      Added value: +"Optional first display-URL path segment (Google allows up to 15\nchars)."
    • addedInput schema / properties / path2 / description
      Added value: +"Optional second display-URL path segment (Google allows up to 15\nchars)."
  3. First observedv0.9.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that the ad is created PAUSED, that final_url is reachability-checked and unreachable URLs are refused, the pinning/fillability validation rule, and that warnings fire below 8 headlines or 3 descriptions. This is exactly the kind of write-behavior and validation context annotations cannot carry.

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 critical scope statement ('PREVIEW, does NOT create') is front-loaded, and the remaining sentences carry non-obvious behavioral rules. It is dense and slightly long, but essentially every sentence adds actionable information rather than restating structured fields.

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?

With an output schema present, return values need not be explained, and the description still covers the confirmation workflow, mutation side effects, URL validation, and pinning constraints. Nothing an agent needs to call this correctly 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 100% (baseline 3), and the description adds real meaning: mixed plain-string/dict entries are permitted in one call, insertion tags count as their default text, and the same position may hold multiple pinned assets. That exceeds what the schema alone conveys, though the schema already documents char limits and pin 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?

The opening line names a specific verb and resource ('Draft a Responsive Search Ad') and immediately disambiguates from actual creation ('returns a PREVIEW, does NOT create the ad'). An agent can distinguish it from update_responsive_search_ad and confirm_and_apply without opening any schema.

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?

It explicitly routes the agent to the follow-up step: 'confirm_and_apply executes the returned plan_id', making the draft-then-confirm workflow clear. It stops short of naming when to prefer this over update_responsive_search_ad or other draft tools, so it is clear context without full alternatives coverage.

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