Skip to main content
Glama

MetricPort

Wasted spend and negative keywords

ads_wasted_spend
Read-onlyIdempotent

Search terms that cost money or clicks but never converted in the period (default 30 days), aggregated across campaigns, with negative keyword suggestions (phrase for recurring words, exact for one-offs).

Input Schema

NameRequiredDescriptionDefault
limitNo
endDateNo
minCostNo
campaignNo
propertyYesGoogle Ads customer id from list_properties, e.g. 1234567890
minClicksNo
startDateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond that: the 30-day default window, cross-campaign aggregation, and the phrase-vs-exact negative keyword suggestion strategy, but says nothing about pagination/limit behavior or result size.

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?

A single dense sentence that front-loads the core concept (wasted-spend search terms) and appends the output detail. Nothing is wasted, though the parenthetical about phrase/exact keywords slightly overloads the sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, no-output-schema tool, the description conveys the analysis and its output well but leaves most filter parameters (limit, campaign, minCost/minClicks defaults) for the agent to infer from the schema. Adequate but with clear gaps.

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

Parameters2/5

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

Schema description coverage is only 14% (just the property field), leaving six of seven parameters undocumented in structured data. The description partially compensates by implying a period default and cost/click thresholds ('cost money or clicks', 'default 30 days'), but never explains limit, campaign, or the startDate/endDate formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource: search terms that spent money/clicks without converting, aggregated across campaigns, plus negative keyword suggestions. This distinguishes it functionally from generic siblings like ads_search_terms and ads_keyword_performance, though it never names an alternative to route between them.

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

Usage Guidelines3/5

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

It supplies the default window (30 days) and the aggregation scope, which implies the intended use case, but there is no explicit when-to-use vs ads_search_terms / ads_keyword_performance guidance and no stated prerequisites such as needing a property id from list_properties.

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.