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

With no annotations, the description carries the full burden and does so well: it discloses the request budget (~1+10 per seed), per-source partial failures surfaced in `errors`, that autocomplete is capped, that spam-like rising queries are ignored, and that clusters carry covered/partial/gap with exclude_covered dropping covered ones. These are exactly the operational traits an agent needs before calling a multi-source network tool.

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?

Front-loaded with the core purpose, then dense but mostly information-bearing sentences; nothing reads as filler. It is a run-on block though, and the bare 'limit: clusters (1-25)' trailing sentence is awkwardly detached from the rest of the description.

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?

An output schema exists, so return values need not be explained, yet the description still adds useful semantics (score_breakdown, coverage categories, errors). For a complex composite tool it is nearly complete, with the only real gap being the unexplained geo and timeframe inputs.

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 coverage is 0%, so the description must compensate, and it explains four of six parameters meaningfully: seeds (1-5), site_queries (definition plus suggested source), exclude_covered (drops covered clusters) and limit (clusters 1-25). It leaves geo and timeframe entirely undocumented, so two parameters remain opaque to the agent.

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 concrete composite purpose: it finds AEO opportunities by clustering question-shaped searches and scoring them against trend, news, wiki, site-coverage and citability signals. This implicitly distinguishes it from single-source siblings like mine_questions, news_coverage and wiki_attention, which it composes. It never names an alternative or defines the 'AEO' acronym, so a reader must infer the domain.

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 through the seed/site_queries framing and by the note to fill site_queries from a Search Console MCP or page titles, which tells the agent how to prepare input. However there is no explicit when-to-use-this vs. the many sibling tools (e.g. when to call this composite instead of mine_questions + news_coverage). The one actionable routing hint is about sourcing site_queries, not about tool selection.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: 5 requests with web queried first and the remainder 'skipped' on a 429 (rate-limit handling), plus the crucial semantic that channels are separate 0-100 scales. This is genuine behavioral context beyond the schema. It omits auth requirements and any error behavior beyond 429, keeping it from a 5.

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?

It is compact and front-loads the core purpose before the output shape and the request/scale caveats. Some terse shorthand ('direction / direction_now / growth_3m') is dense but each clause carries information.

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?

An output schema exists so return values need not be explained, and the description covers behavior and interpretation well. However, for a 3-parameter tool with 0% schema coverage, the near-total absence of parameter semantics leaves the definition incomplete for correct invocation.

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% and the schema provides no descriptions, so the description must compensate. It only loosely implies the keyword via 'a topic' and says nothing about geo or timeframe, leaving two of three parameters entirely undocumented.

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?

The description names the resource (Google properties/channels: web, youtube, news, images, shopping) and specifies the comparison output (direction, direction_now, growth_3m, fastest_channel, format_hint). It is far from a tautology and lets an agent understand what the tool produces. It stops short of explicitly distinguishing itself from the sibling compare_keywords, so a 5 is not warranted.

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?

There is no explicit when-to-use guidance and no mention of when to prefer this over siblings like compare_keywords or trending_now. The only usage-adjacent content is an interpretive caveat ('compare growth, never means'), which is not routing guidance.

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

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

No annotations are provided, so the description carries the burden. It discloses the core behavior (comparison, relative share, leader, trend direction) but doesn't mention limitations like data availability, normalization, or how 'leader' is determined. It's adequate but not rich.

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?

Two sentences, front-loaded with the core action and output, followed by a clear use case. No wasted words.

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?

The tool has an output schema, so return values are covered. However, with no annotations and 0% schema coverage, the description should explain more about the optional parameters and any constraints (e.g., keyword count limits, required format). It's adequate for a simple comparison tool but leaves some gaps.

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 must compensate. It explains the 'keywords' parameter implicitly (2-5 keywords) but doesn't explain 'geo', 'gprop', 'category', or 'timeframe'. The description adds some meaning for the main parameter but leaves the optional parameters undocumented.

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?

The description uses a specific verb ('Compare') and resource ('keywords head-to-head'), and clearly states what it produces: relative share, leader, and trend direction for each keyword. It also distinguishes itself from siblings by focusing on comparison rather than single-keyword trends or related queries.

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?

The description explicitly states when to use this tool: 'Use to pick the strongest angle among alternatives.' This gives clear context for selection. It doesn't explicitly name alternatives or exclusions, but the sibling list and the comparison-focused wording make the intended use clear.

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

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

With no annotations provided, the description carries the behavioral burden and does well: it discloses deduplication, ranking tiers, partial-failure reporting via errors, rate-limit caution, and coverage tagging. It still omits explicit safety/auth or read-only guarantees, but the behavioral picture is strong.

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?

The description is dense but front-loaded and nearly every sentence adds concrete information about behavior or parameters. It is a single long paragraph rather than structured bullets, which slightly reduces readability, but it avoids empty filler.

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?

Given an output schema, the description need not detail return values, yet it still explains output fields and failure modes well. The main gap is that several input parameters remain undocumented despite 0% schema coverage, so an agent lacks full parameter context.

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 must compensate for 8 parameters. It explains seed_keywords (1-5 seeds), site_queries, exclude_covered, and the resulting coverage labels, but leaves geo, gprop, category, timeframe, and max_per_seed unexplained, providing only partial compensation.

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?

The description states a specific verb and resource: 'One-shot topic discovery for blog ideation,' and clarifies it pulls trend context plus related queries and ranks candidates. It does not, however, explicitly distinguish itself from siblings such as related_queries or trending_now, so it falls short of the top score.

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?

It gives clear usage context ('for blog ideation'), guidance to start with 1-2 seeds on the first call to avoid 429s, and explains when to supply site_queries. It does not state when-not to use this tool or name alternative sibling tools, so it is not fully explicit.

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

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

With no annotations, the description carries the full behavioral burden and does disclose the important constraint matrix between resolution and geo, including the non-US REGION-only limitation. It says nothing about read-only nature, rate limits, pagination, or error behavior, so it is only partially transparent.

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?

Two compact sentences with the core purpose front-loaded and no filler. The shorthand notation ('geo='' only') is dense but readable, and nothing is wasted.

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 7-parameter tool with 0% schema description coverage and no annotations, the description covers only the resolution/geo interaction. The return shape is arguably handled by the output schema, but the remaining call-critical parameters are left entirely unexplained.

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 coverage is 0% across 7 parameters, so the description must compensate. It explains the semantics and valid values of resolution and its coupling to geo, but says nothing about keywords, timeframe, gprop, category, or limit, leaving most parameters undocumented anywhere.

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?

The opening phrase 'Where a keyword is searched most' states the resource and the breakdown dimension (geography) clearly, which separates it from the time-oriented sibling interest_over_time. It is not a clean verb+resource statement and no sibling is named explicitly, so it lands just short of a 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?

The resolution/geo compatibility rules ('COUNTRY (geo='' only)', 'CITY and DMA ... geo='US' or worldwide only') effectively tell the caller when a given configuration is legal, which is real usage guidance. However, there is no guidance on when to choose this tool over interest_over_time or related_queries.

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

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

With no annotations, the description carries the full behavioral burden and does disclose meaningful traits: results are downsampled to ~60 points, direction_now is a recent slope, direction may read as rising/new on stale peaks, and gprop channels have differing authority for answer engines. It still omits read-only/safety framing and any rate-limit or quota expectations for a Trends-backed call.

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?

A single dense paragraph that front-loads what the tool returns and follows with parameter guidance; there is little waste. The embedded output-field inventory (mean, latest, peak, growth_3m/12m) is slightly list-heavy but each item is informative.

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?

An output schema exists, so the description did not need to enumerate return values, yet it does so usefully. For a 5-param, zero-coverage read tool with no annotations, the main remaining gaps are the semantics of geo, category, and timeframe, which an agent needs in order to call it correctly.

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 coverage is 0%, so the description must compensate. It does well on two params (keywords bounded to 1-5, gprop values enumerated as ''/news/youtube/images/froogle with a rationale), but geo, category, and timeframe are never explained, leaving half the parameters semantically invisible to the agent.

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?

The description opens with a specific verb+resource+scope: 'Search-interest time series (0-100) for 1-5 keywords'. It is easily distinguished from siblings like interest_by_region, trending_now, and compare_keywords because it explicitly frames the output as a per-keyword time series with direction metrics.

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?

It gives one concrete usage rule ('Use direction_now to decide whether to write about a topic *now*') and warns that 'direction can be rising or new for a topic that peaked months ago', which is a useful interpretive guardrail. However, it never says when to prefer this tool over compare_keywords or related_queries, so routing guidance is only implied.

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

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

There are no annotations, so the description carries full responsibility for disclosing behavior. It does strongly indicate a read/browse/search action and gives an example of the output form. However, it says nothing about how the limit parameter behaves, whether the empty search returns all categories, or if the list is sorted—a moderate gap for a read-only tool with no pre-existing annotation context.

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?

The entire description fits into two sentences and carries immediate value. The first word is the primary verb, a concrete example is embedded naturally, and the final sentence tells exactly what to do with the result. No repetition or filler—every clause earns its place.

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?

Given that an output schema exists, the description does not need to explain return fields. It sufficiently covers what the tool's purpose, how to invoke it, and how to apply results in the broader tool set. The only real gaps are the unresolved semantic of the limit parameter and some search matching details, which lower the score from a perfect context.

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 must take on the burden of explaining parameters. It gives an example of what 'search' is for ('coffee' -> category path) and implies 'browse' covers the limit case, but it never mentions the limit parameter by name or explains its behavior. With only 2 parameters, both undocumented at schema level, a clear explanation of one is not enough; this is a meaningful gap.

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?

The description starts with a specific verb and resource: 'Browse/search Google Trends category ids.' It gives a concrete example ('coffee' -> Food & Drink > Coffee & Tea) and explicitly explains its output is used by passing the id to other tools. This clearly distinguishes the function from its trend-analysis siblings, which operate on time series and related terms.

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?

The description states when to use the tool: when you need category IDs to narrow other tools' results. It does not explicitly mention when not to use it or name alternate siblings like suggest_keywords, but the use case is clear enough. It provides a strong implication of usage but leaves exclusions and alternatives unstated.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It mentions throttling (up to ~16 requests per call), 24-hour caching, de-duplication, and tagging with a title angle. These are concrete behaviors that help the agent understand side effects and constraints. It does not mention read-only nature, but that is implied by the operation. The coverage is strong for a read-only mining tool.

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?

The description is a single, dense sentence that packs purpose, examples, behavioral details, and limit into a compact form. It is front-loaded with the core purpose. While it could be split for readability, every clause adds useful information, and it avoids redundancy. It is appropriately concise for the amount of detail.

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?

An output schema exists, so return values are covered. However, the description lacks parameter semantics and explicit usage guidance. It does not explain how 'seed' and 'geo' affect results, nor does it mention any ordering or filtering behavior. The behavioral details (throttling, caching) are good, but the missing parameter explanations and sibling differentiation make the tool incomplete for an agent to call it correctly without additional context.

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 must compensate for parameter explanations. It only mentions 'limit: 1-100' in the description, providing a range for that parameter. However, it does not explain what 'seed' refers to (beyond being a starting topic) nor the meaning or possible values of 'geo'. With three parameters and 0% schema coverage, this is a significant gap that leaves the agent guessing about required input semantics.

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?

The description clearly states the tool mines long-tail questions from Google Autocomplete for a given seed, with explicit examples of expansions ('how to', 'why', 'what is', 'vs'). It distinguishes itself from siblings like related_queries or suggest_keywords by focusing on question-form queries and mentions the downstream use (FAQ, AEO content). The verb 'mine' plus resource 'questions' is specific and unambiguous.

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?

The description implies usage by mentioning 'Feeds FAQ sections and answer-engine (AEO) content', which tells the agent when this tool is relevant. However, it does not explicitly contrast with sibling tools (e.g., related_queries, suggest_keywords) or state when not to use it. The context is present but not explicit, so the agent must infer the distinction.

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

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

With no annotations, the description carries the full burden; it usefully discloses a 15-minute cache and the limit range (1-50), which the schema does not. However it says nothing about the geo parameter's behavior, error cases, or whether results are scoped or sampled, leaving meaningful behavioral gaps for a network-backed tool.

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, front-loads the output-focused purpose, and appends operational facts (cache, limit) without padding. Slight awkwardness in the enumerated list, but no wasted sentences.

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?

An output schema exists, so return-shape explanation is not strictly required, yet the description still names the outputs, adds caching and limit bounds, and gives a use-case hint. Only the geo parameter's meaning and scope remain unaddressed.

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% across 3 parameters, so the schema contributes nothing. The description rescues 'limit' by defining it as headlines returned with a 1-50 range (bounds absent from the schema), but 'topic' and 'geo' receive no semantic elaboration beyond their names.

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 verb+resource ('who is covering a topic in Google News') and enumerates the three outputs returned: headlines, a publisher frequency table, and a recency histogram. The Google News source is named, which separates it from wiki_attention and interest_over_time among siblings.

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?

The parenthetical '(mention / pitch targets)' hints at a PR/media-outreach use case, but the description never states when to prefer this over siblings like trending_now or wiki_attention, nor any exclusions or prerequisites. Usage is only implied.

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

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

With no annotations, the description must carry the full behavioral burden. It does disclose meaningful output behavior — rising includes % growth and is_breakout >5000%, suspect=true spam items are excluded from `questions` — but says nothing about auth needs, rate limits, failure modes, or geo/gprop behavior, leaving the procedural side dark.

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?

One dense paragraph front-loaded with the core purpose, then the semantic details of rising/questions/suspect. Every clause about flags and filtering earns its place; sizing is appropriate for the amount of return-shape nuance conveyed.

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?

An output schema exists, so return-value explanation isn't required, yet the description covers it well. The gap is input-side: five of six parameters are undocumented in both schema and description, and with no annotations the safety/permission profile is entirely absent.

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 coverage is 0% across 6 parameters, and the description documents only the implicit `keyword`. It says nothing about geo, gprop, limit, category, or the timeframe default ('today 3-m'), so an agent must guess at values and formats for five undocumented inputs.

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 resource — 'top and rising search queries related to a keyword' — and specifies the sub-shapes it returns (rising, is_breakout, questions, suspect). It positions itself as 'best single source of fresh blog angles,' which hints at a niche, but it never names siblings like related_topics or suggest_keywords to draw a hard boundary.

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?

The closing line 'Best single source of fresh blog angles' implies when the tool is the right pick, but there are no explicit when-not conditions and no named alternatives despite 13 siblings with overlapping surface (related_topics, suggest_keywords, mine_questions).

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

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

With no annotations provided, the description carries the behavioral burden. It discloses a non-obvious trait—that Google often returns no data—and explains the availability flag semantics. This goes beyond a basic summary, though it does not detail all response behavior or edge cases.

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?

The description is two concise sentences with the core purpose front-loaded and the important fallback caveat placed second. Every word earns its place.

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?

The description is useful for basic invocation and fallback decisions, and the output schema covers return values. However, with six parameters and zero schema descriptions, the lack of parameter guidance leaves meaningful gaps for correct invocation with non-default options.

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 must compensate for the six parameters, but it only mentions 'keyword.' The meanings of geo, gprop, limit, category, and timeframe are left entirely to inference from their names and defaults.

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?

The description clearly states that the tool returns 'Top and rising Knowledge-Graph topics related to a keyword,' identifying both the specific verb and resource. It also differentiates from the sibling tool related_queries by mentioning the fallback path, so an agent can distinguish them.

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?

The description gives explicit guidance: Google often returns nothing here, and if available=false the agent should fall back to related_queries. This directly tells the agent when to use the tool and when to switch to an alternative.

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

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

With no annotations, the description must carry the behavioral burden, and it does disclose real behavior: the 5-year weekly data basis, that it is a single request, and that seasonal=null is returned with a reason when fewer than 3 full years exist. It does not cover auth, rate limits, or cost, keeping it short of a 5.

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?

Two dense sentences, front-loaded with the purpose, then the return payload, then the edge case. Every clause carries distinct information and nothing is repeated from the schema.

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?

An output schema exists, so return values need not be spelled out, yet the description usefully names the key fields and the null-return condition. Combined with the keyword-only required parameter, an agent has enough to call it correctly; only parameter-level semantics are missing.

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 both parameters (keyword, geo) are undocumented in structured data. The description never compensates — it does not explain geo semantics (default empty string behavior) or keyword expectations. Parameter names are largely self-evident, which prevents a 1, but the gap is real.

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?

The description names a specific resource and analytical output: when demand for a keyword peaks each year, returning monthly_index, peak_months, seasonal_strength, next_peak and publish_by. It is clearly distinct in spirit from siblings like trending_now or interest_over_time, but it never explicitly differentiates itself from them, which is the one gap separating it from a 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 agent can infer this is the tool for seasonal planning (e.g. publish_by timing), and the null-with-reason edge case is documented. However, there is no explicit when-to-use vs. when-to-prefer interest_over_time/trend_history guidance or any prerequisite statement.

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

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

No annotations are present, so the description carries the burden. It discloses that this is a read-style suggestion API and what it returns. It does not mention errors, limits, or external dependencies, but for this simple tool the core behavior is clear.

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?

Two dense sentences with no wasted words: output shape first, then concrete usage scenarios.

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 simple one-parameter read tool with an output schema, the description covers purpose, response fields, and usage context. It stops short of documenting edge cases or output size limits, but the core calling context is complete.

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?

The schema gives no parameter descriptions, so the description compensates by clarifying that the keyword is used to retrieve entity suggestions and can disambiguate ambiguous terms. It could add input format details, but the one-parameter surface is simple.

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 concrete operation—returning Google entity suggestions for a keyword—and identifies the response fields (title, type, mid), distinguishing it from trend/time-series siblings.

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?

Gives explicit use cases: disambiguate ambiguous terms or find the canonical topic ID. It doesn't name sibling tools or when not to use the tool, but the guidance is still actionable.

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

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

No annotations exist, so the description carries the full burden. It discloses that the operation is local and free with no network requests, constrains `days` to 1-365, and explains the semantics of breakout_episodes (>= 3 = recurring, durable page) versus breakout_observations (polling count). It stops short of stating any auth or permission requirements.

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?

Single dense sentence with the core 'local archive' framing front-loaded, followed by field semantics and the free/no-network note. The parenthetical detail earns its place, though the sentence is long and packed.

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?

An output schema exists, so return-value documentation is a bonus rather than a requirement, and the description still outlines the key fields. The only real gap for an agent is the unexplained `geo` parameter; otherwise the tool is adequately covered for a local read.

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 must compensate. It explains `keyword` (seed or related query under other seeds) and bounds `days` to 1-365, but says nothing about the `geo` parameter, leaving one of three parameters semantically undocumented.

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?

The description states a specific resource — a local archive of observations about a keyword — and distinguishes itself from live-data siblings by noting it 'makes no network requests'. It is clear what the tool returns, though it never names the sibling tools it contrasts with.

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: 'local archive' and 'Free: makes no network requests' suggest reaching for this instead of live-fetching tools, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative.

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

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

With no annotations, the description carries the full burden, and it does disclose non-obvious behavior: the ~24h recency window, that traffic numbers are approximate, and that filtering still fetches and caches the full feed. It omits auth/permission needs, rate limits, and error behavior, so it is strong but not complete.

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?

Three dense sentences that front-load the what and recency window, then the filter semantics, then the caching caveat. No filler, though the trailing cache note could be tightened.

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?

An output schema exists, so return-value explanation is unnecessary, and the description covers purpose, filter semantics, and caching. But with zero schema coverage, no annotations, and a trivial 'Geo'/'Max Articles' schema, the agent still lacks the geo value format and the meaning of max_articles — real gaps for a 3-parameter tool.

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 coverage is 0%, so the description must compensate. It explains topic_filter precisely ('title or headlines contain every word given', with an example) and gestures at geo ('country or US state'), but never states the expected geo format (code vs. name) and says nothing about max_articles. Two of three parameters get meaningful help; the third is left entirely to inference.

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 verb and resource: 'Real-time trending searches (last ~24h) for a country or US state', plus what accompanies each trend (approximate traffic, linked headlines). That is far more specific than a name restatement. It does not, however, differentiate itself from siblings such as news_coverage, related_queries, or interest_by_region, which an agent must still disambiguate on its own.

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?

'Good for newsjacking' implies a usage context but names no alternative tool and gives no when-not condition. An agent can infer this is the real-time snapshot tool, but nothing explicitly routes it away from interest_over_time or news_coverage.

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

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

With no annotations present, the description carries the full burden and does reasonably well: it discloses that the call performs no network requests, and it specifies the exact behavioral states reported (live / error / idle with last error, cache usage, archive rows/dates/last_error). It does not state auth requirements, rate limits, or confirm read-only semantics outright, but 'makes no network requests' strongly implies a side-effect-free read.

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?

A single dense sentence enumerating exactly what the status report contains, with the key constraint ('free, no network requests') placed last as a qualifier. No filler and nothing that fails to earn its place.

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?

An output schema exists, so return values need not be spelled out, and the description still summarizes the reported categories usefully. The only gap is the absence of any trigger guidance for a diagnostics tool, which is minor given its zero-parameter simplicity.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies since no parameter semantics are required.

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 purpose: reporting health of each data source (google_trends, google_autocomplete, google_news, wikipedia), cache usage, observation archive, and effective settings. The enumerated resources make it clearly a diagnostics/status tool, distinct from the data-querying siblings, though no sibling is named explicitly.

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?

'Free: makes no network requests' implies this is a safe, costless call to make before or instead of network-dependent tools, which is real usage guidance. However, it never states the diagnostic conditions that should trigger a call (e.g., after an error, to check quota/state), so usage remains implied rather than explicit.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: it refreshes data first ('1 + N requests, cached'), compares against a local observation archive that is populated by other tools, and returns a per-seed reason with a rerun date when no baseline exists. It also warns that leaving Google's relative list is not proof of falling demand. It stops short of stating auth/permission needs or result limits.

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?

The purpose is front-loaded and most content earns its place, but the body is a dense run-on of fragments and internal shorthand ('old:', 'direction_now', 'rank_moves') that forces the reader to decode labels. Readability suffers even though little is truly redundant.

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?

An output schema exists, so return shape needn't be explained, and the description still adds semantic meaning for the change categories and the no-baseline case. Combined with the refresh/archive behavior and the seeds/since_days constraints, an agent has enough to invoke it, with geo as the only gap.

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 coverage is 0%, so the description must compensate. It adds two useful constraints absent from the schema: seeds limited to 1-5 and since_days bounded to 1-90. However, the third parameter (geo) is never explained, leaving one of three parameters undocumented in both schema and description.

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?

The opening clause 'What changed for 1-5 seeds since the last snapshot' states a specific comparison/delta operation over a named resource, and the body names the change categories (new_breakouts, new_rising, cooled/dropped, rank_moves, direction_flip). It is clearly distinct from interest_over_time, which it explicitly routes to. The phrasing is cryptic but the purpose is recoverable.

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?

It gives per-outcome action guidance ('investigate now', 'consider', 'review: verify with interest_over_time before retiring, or refresh existing post') and names the alternative tool plus the condition for using it. It does not state when NOT to use this tool at all (e.g., for a single seed vs many), but the routing advice is concrete.

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

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

With no annotations, the description carries the full burden and does well: it discloses a dedicated rate lane ('Own rate lane'), a 24-hour cache, and the branching failure mode (has_article=false with a related_article suggestion). It does not mention auth requirements or pagination, so it falls short of a perfect 5.

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?

The core question is front-loaded in the first sentence, followed by output shape and constraints. It is dense and slightly cramped, but every sentence carries information; no filler.

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 3-param tool with an output schema, the description is complete: it covers inputs, return shape, fallback behavior, caching, and rate-lane characteristics. An agent has everything needed to call it and interpret results despite zero schema description coverage.

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 coverage is 0%, so the description must compensate, and it does: it documents the `days` range (7-90), `lang` as the Wikipedia edition with examples ('en', 'pt', 'de'), and `topic` implicitly via the exact-title lookup. It omits the default value for `days`/`lang` but adds real meaning beyond the bare 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 verb and resource: it answers whether Wikipedia has an exact-title article for a topic and whether attention is growing. The output contract (exact article fields, daily pageviews, has_article=false fallback) is spelled out, so an agent can distinguish it from siblings like interest_over_time or news_coverage.

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?

It hints at usage ('verify gaps before citing') and describes what happens when no exact article exists, which implies a validation use case. However, it never explicitly contrasts itself with any sibling (e.g., interest_over_time for Google Trends vs. this for Wikipedia), leaving the when-to-choose decision to inference.

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