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: d80f65c0.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "customer_id": "<customer_id>",
      "shared_set_id": "<shared_set_id>",
      "keywords": "<keywords>"
    },
    "name": "remove_from_negative_keyword_list"
  }
}

Input Schema

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

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the destructive/idempotent annotations: it discloses blast radius ('every campaign the list is attached to can show for those searches again'), the spend consequence, that the list and its campaign links survive, the list-type restriction, and that a no-match call sends nothing. That is exactly the context an agent needs before invoking a destructive tool.

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-loaded with the core action and consequence, then constraints, then args/returns — well structured. The parenthetical '(and of the keywords create_negative_keyword_list was given)' is awkward filler, and the Returns section partly restates the output schema, but neither is costly.

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?

Covers the mutation semantics, matching rules (case and whitespace insensitive, match type must agree), partial-failure behavior via not_found, and the no-op case. Even though an output schema exists, the extra explanation of what removed/not_found mean is genuinely clarifying rather than redundant.

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 coverage is 0% and the schema types keywords as bare string maps, so the description carries the full burden: it specifies customer_id is digits-only without hyphens, shared_set_id is digits-only, and that each keyword object needs text plus a match_type of EXACT/PHRASE/BROAD defaulting to BROAD. This is information the schema cannot supply.

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?

Uses a specific verb ('takes negative keywords back out of') on a specific resource ('shared negative keyword list') and immediately names its inverse operation, so the agent can place it against add_to_negative_keyword_list and create_negative_keyword_list 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 Guidelines5/5

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

States the use condition (inverse of add_to_negative_keyword_list, pass the same text and match type) and an explicit exclusion with the correct alternative ('the account-level list is changed with remove_account_negatives'). Nothing is left to inference about which sibling to pick.

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?