Skip to main content
Glama

Opus Growth, Ad Platforms MCP Connector

Update Responsive Search Ad

update_rsa
Destructive

EDITS the copy of an existing Google Ads RESPONSIVE SEARCH AD (RSA) in place — swap, drop or add a headline or description while keeping the SAME ad and its performance history. This is the tool for "remove that one headline", "replace this description", "add two more headlines"; rebuilding the ad instead would reset its learning, burn one of the 3 enabled-RSA slots in the ad group, and leave a paused near-duplicate behind.

TWO WAYS to give the change, and the partial one is usually what you want: • PARTIAL (recommended): remove_headlines / add_headlines / remove_descriptions / add_descriptions. The live ad is read first, only your delta is applied, and everything you did not mention — including each surviving asset's PIN — is written back unchanged. remove_* matches on the exact text; a text that is not in the ad is reported instead of silently ignored. • FULL REPLACE: headlines / descriptions replace ALL existing ones, so you must re-send every line you want to keep. Do not mix the two for the same field. Google limits either way: 3-15 headlines ≤30 chars, 2-4 descriptions ≤90 chars — checked before the call, so an edit that would leave too few is refused rather than rejected by Google.

final_url/path1/path2 optional. To change ONLY the destination URL, pass just final_url (leave the copy fields empty) — this updates final_urls on standard ads (RSA and other final-URL ad types). NOTE: call-only ads (CALL_AD) do NOT allow their URL to be edited via the API (Google returns VALUE_MUST_BE_UNSET); a call ad must be recreated with the new URL. To DELETE an ad entirely use update_ad_status(status='REMOVED'). PINNING: headline_pins / description_pins are optional lists in the SAME ORDER as the headlines/descriptions given; each entry pins that text to a fixed position — headline 1/2/3, description 1/2 (0/empty = unpinned). E.g. headline_pins=[1,0,0] pins the first headline to position 1. Google's own field names are accepted too, so headline_pins=['HEADLINE_1','',''] means the same thing. A position-to-text dictionary is NOT accepted — the list must follow the same order as the headlines you send. Text or pin changes start a new Google review. Pins are part of the replaced content, so send them together with the headlines/descriptions. confirm=false → dry-run.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ad_idYes
path1No
path2No
confirmNo
final_urlNo
headlinesNo
customer_idYes
descriptionsNo
add_headlinesNo
headline_pinsNo
add_descriptionsNo
description_pinsNo
remove_headlinesNo
remove_descriptionsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added
  4. Removed
  5. Added
  6. Removed
  7. Added
  8. Removed
  9. Added
  10. Removed
  11. Added
  12. Removed
  13. Added
  14. Removed
  15. Added
  16. Removed
  17. Added
  18. Removed
  19. Added
  20. Removed
  21. Added
  22. Removed
  23. Added
  24. Removed
  25. Added
  26. Removed
  27. Added
  28. Removed
  29. Added
  30. Removed
  31. Added
  32. Removed
  33. Added
  34. Removed
  35. Added
  36. Removed
  37. Added
  38. Removed
  39. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructive/non-idempotent, and the description adds substantial context beyond them: partial vs full replace semantics, that unmatched remove_* text is reported rather than ignored, pre-call Google limit validation (3-15 headlines ≤30 chars, 2-4 descriptions ≤90 chars), the call-only ad VALUE_MUST_BE_UNSET restriction, that edits trigger a new Google review, and confirm=false dry-run behavior.

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?

Long but densely structured with bullets and labeled sections, and the core distinction (partial vs full replace) is front-loaded. Given 14 undocumented parameters, nearly every sentence earns its place, though it is slightly verbose in places (e.g., the pinning example redundancy).

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 14-parameter mutation tool with an output schema (so return values need not be described), the description covers the operation modes, constraints, pre-call validation, platform-specific caveats, and safety routing. An agent has everything needed to invoke it correctly.

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 0% schema description coverage, the description carries the burden and does most of it well: it explains the partial (add_*/remove_*) vs full (headlines/descriptions) families, that they must not be mixed, pin list ordering and accepted formats, and the final_url-only edit case plus confirm dry-run. The one gap is path1/path2, which are only called 'optional' with no explanation of their URL-path purpose.

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 ('EDITS the copy of an existing ... RESPONSIVE SEARCH AD in place') and immediately scopes the operation by its effect on the existing ad and its history. It clearly distinguishes itself from create_responsive_search_ad and update_ad_status ('To DELETE an ad entirely use update_ad_status').

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

Usage Guidelines5/5

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

Explicitly names the triggering intents ('remove that one headline', 'replace this description') and warns against the alternative of rebuilding the ad, listing the concrete costs (reset learning, burn an RSA slot, paused near-duplicate). It also routes deletion to the correct sibling tool, covering when/when-not and alternatives.

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.