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

Annotations already cover read-only and open-world, so the description is free to add genuinely new behavior: the aggregation window ends yesterday with today excluded, results are sorted descending by cost, output is capped at 200 rows, and headline/landing-page dimensions are structurally unavailable via the API. That last point is important negative information an agent could not otherwise know. It does not discuss rate limits or empty-result behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Compact and front-loaded: the source split and its purpose come first, then the metric list, then window/sort/limit, then the per-parameter notes. It is one dense paragraph with telegraphic punctuation and some run-on clauses, but nearly every sentence carries information an agent needs.

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

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

For a read-only reporting tool with an output schema, the essentials are present: what is returned, how it is aggregated and sorted, the row cap, the unavailable dimensions, and all four filters. Minor gap: it does not point to where headline/landing-page data can instead be obtained, which would help an agent recover from that limitation.

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

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 burden and largely meets it: days is defined as the aggregation window ending yesterday (today excluded), campaign_id as an optional single-campaign filter, min_cost_eur as a cost threshold that hides combinations below it, and workspace as a customer slug that is optional when only one workspace exists. The only gap is that the days=30 default and the exact semantics of the 200-row cap interaction with min_cost_eur are left to the schema.

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

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

States a specific operation: a source split per search term × campaign returning the official source (KEYWORD / AI_MAX_KEYWORDLESS / AI_MAX_BROAD_MATCH / BROAD_MATCH) plus metrics. It also declares its analytical purpose ('Deckt Off-Target-Streuung der AI-Max-Expansion auf'), which differentiates it from ads_search_terms and ads_performance-style siblings in substance. It stops short of naming a sibling it is not, so 4 rather than 5.

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

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

Usage is implied rather than stated: the reader can infer this is the tool for AI Max keywordless/broad-match spillover analysis, and the note that headline/landing page data is NOT available is a useful scope exclusion. There is no explicit 'use this when / use X instead' routing against ads_search_terms or ads_pmax_search_insights, and no prerequisites are mentioned.

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