AdCopilot

Google Ads: remove from negative keyword list

remove_from_negative_keyword_list

DestructiveIdempotent

Takes negative keywords back out of a shared negative keyword list.

The inverse of add_to_negative_keyword_list (and of the keywords
create_negative_keyword_list was given): pass the same text and match
type. Every campaign the list is attached to can show for those
searches again at once, which can raise what a running campaign spends.
Only a list of type NEGATIVE_KEYWORDS is accepted; the account-level
list is changed with remove_account_negatives. The list itself, and its
links to campaigns, are never removed.

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; when none is found, nothing is sent.

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

Returns:
    Dictionary with removed (text, match_type and resource_name of each
    keyword taken out), not_found (each keyword the list did not hold)
    and keywords_removed.

Tools revision: 5c9bea8f.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`keywords`	Yes
`customer_id`	Yes
`shared_set_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (destructive, idempotent, non-readonly), the description discloses real consequences: spend can rise across every attached campaign, the list and its campaign links are never removed, and non-matching keywords are surfaced in not_found with nothing sent when none match. This adds substantive behavior the annotations cannot convey.

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?

Front-loads the core action, then constraints, then args/returns; on the whole tight. A couple of repeated parenthetical references to add_to_negative_keyword_list are slightly redundant but not wasteful.

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?

Given a mutation tool with 3 required params at 0% schema coverage, the description covers identity/purpose, side effects, preconditions, matching semantics, error handling, and even return fields. Nothing an agent needs to invoke it safely 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 0%, so the description carries the full burden and does: customer_id is digits-only without hyphens, shared_set_id is digits-only, and each keyword needs text plus a match_type enum (EXACT/PHRASE/BROAD, default BROAD) plus the case/whitespace-and-match-type matching rule. Value is strong; only the keyword object shape (schema uses free-form additionalProperties) is not fully pinned down.

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+resource ('Takes negative keywords back out of a shared negative keyword list') and explicitly names what it is the inverse of and what it is not (remove_account_negatives), so an agent can position it against siblings like add_to_negative_keyword_list and remove_negative_keywords without reading schemas.

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 routes the agent: use this for a NEGATIVE_KEYWORDS shared list, use remove_account_negatives for the account-level list, and pass the same text/match_type as add_to_negative_keyword_list. Both the when and the when-not are stated.

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

All AdCopilot tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?