Skip to main content
Glama

Google Ads: remove account-level negative keywords

remove_account_negatives
DestructiveIdempotent

Takes account-level negative keywords back out.

The inverse of add_account_negatives: pass the same text and match
type. Every campaign in the account can show for those searches again
at once, running ones included, which can raise what they spend. Only
keywords are taken out of the account-level list; the list and its link
to the account stay, even when it is left empty. An account with no
account-level list has nothing to take out: every keyword is reported
in not_found and nothing is created or sent.

Text is matched ignoring case and extra spaces, and the match type must
match too. A keyword the list does not hold is reported in not_found
and nothing is done for it.

Args:
    customer_id: The Google Ads customer ID (numbers only, no hyphens).
    keywords: List of keyword objects, each with:
        - text: The keyword text (e.g., "free").
        - match_type: One of: EXACT, PHRASE, BROAD. Default: BROAD,
          as in add_account_negatives.

Returns:
    Dictionary with the account-level list's shared_set_id (null when
    the account has none), removed (text, match_type and resource_name
    of each keyword taken out), not_found and keywords_removed.

Tools revision: 5c9bea8f.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keywordsYes
customer_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The annotations already mark this as destructive but idempotent. The description adds the key behavioral consequences: every campaign can show for those searches again, spend may rise, only keywords are removed, and the account-level list and its link remain.

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 front-loaded with the action and its main warning, then structured into Args and Returns. It is somewhat long, but most detail is necessary because the schema provides no parameter descriptions.

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 destructive, idempotent Google Ads mutation, the description covers effects, edge cases, matching behavior, parameter details, and return values. An output schema exists, but the description still gives useful return context without relying on it alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full parameter burden. It documents customer_id formatting, the keywords list structure, text fields, match_type values, and the BROAD default.

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 states a specific verb and resource: taking account-level negative keywords back out. It explicitly frames itself as the inverse of add_account_negatives, making the scope and sibling distinction clear.

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?

It explains exactly when this tool applies: pass the same text and match type used when adding. It also covers edge cases, including accounts with no account-level list and keywords not present in the list, so the agent knows when removal is a no-op.

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