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 full burden and does it well. It explains the ranking logic ('breakout > rising > evergreen'), the input constraint (1-5 seeds), and the failure mode ('partial failures reported per seed in errors instead of failing'). This gives the agent clear expectations about side effects and error handling.

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 compact and front-loaded: it identifies the operation, input constraint, output behavior, and error semantics in two sentences. Every clause earns its place, with no fluff or repetition.

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 is present, so return-value structure does not need to be spelled out. The description gives the purpose, input shape, ranking semantics, and partial-failure behavior. What's missing is any guidance on how optional parameters affect resultscars, so an agent may not know how to use geo/timeframe/category effectively.

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 description only clarifies seed_keywords (1-5) and that errors are reported per seed. The other five parameters—geo, gprop, category, timeframe, and max_per_seed—are left entirely undocumented in both schema and description. The description does not compensate for the schema's lack of parameter guidance.

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 and complete statement: 'One-shot topic discovery for blog ideation.' It then details the exact input (1-5 seed keywords) and what the tool does with it — pulls trend direction and related queries, then de-duplicates and ranks candidates by breakout > rising > evergreen. This clearly identifies the tool's function and distinguishes it from sibling tools like related_queries or trending_now.

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 a clear use case ('blog ideation') and the input constraint (1-5 seed keywords), but gives no explicit guidance on when to prefer this tool over siblings such as related_queries, trending_now, or interest_over_time. There is a hint of differentiation via 'one-shot' and the ranking behavior, but an agent would have to infer the tool's unique fit.

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 must disclose behavior itself. It only reveals that results are geographically aggregated and offers resolution choices; it does not state read-only behavior, output ordering, limits, pagination, or date-window handling. Too little behavioral context for a tool that could return anything from a ranking table to raw search-volume data.

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 short and places the core purpose first, with the resolution semantics following immediately. It is compact and scannable, though it omits detail rather than wasting 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?

For a tool with seven parameters scrub coverage, no annotations, and no usage guidance, this description is materially incomplete. An agent would not know how to set geo, gprop, or time range, nor what the response structure implies. The presence of an output schema helps, but the invocation context is under-specified.

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 effectively 0%, so the description must compensate. It explains the resolution parameter and hints at the keyword input, but leaves geo, gprop, limit, category, and timeframe entirely unexplained. This is insufficient for an agent to construct valid calls without extra 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?

The description clearly identifies the tool's purpose: locating where a keyword is searched most, which distinguishes it from the sibling interest and comparison tools. The resolution list adds concreteness by showing the geographic scopes it supports, though it never names an alternative tool 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?

The phrase 'Where a keyword is searched most' gives a reasonable indication to use this tool for geographic search-interest questions. However, there is no explicit guidance about when to choose it over siblings like compare_keywords or interest_over_time, and no exclusions or prerequisites are mentioned.

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 behavioral burden. It discloses the 0-100 scale, per-keyword summary fields, downsampling to ~60 points, and valid gprop values — good behavioral context. However, it doesn't state that this is a read-only operation, any authentication prerequisites, rate limits, or behavior for invalid keyword counts, though the 'search-interest' wording makes mutation unlikely.

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 extremely succinct: three sentences contain zero filler and front-load the core purpose. The single-line gprop value list is an efficient way to convey allowed values. Every phrase 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?

For a tool with 5 parameters, no annotations, and no schema description, the description leaves too much unexplained. It fails to explain the crucial optional parameters geo, category, and timeframe, and does not specify their formatting or intended use. While the output schema exists, the description is incomplete for correctly using the tool's full feature set.

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 input schema has 5 parameters and schema description coverage is 0%, so the description must compensate. It explains only gprop (with accepted string values) and keywords, while geo, category, and timeframe are completely absent. An agent cannot know what geo/category values mean or how timeframe strings like 'today 12-m' relate to output; thus the description only partially covers parameter 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's function: search-interest time series for 1-5 keywords with per-keyword summaries. It differentiates from some siblings (e.g., interest_by_region) through temporal focus, but it does not explicitly contrast with closely related tools like compare_keywords, which could also provide time-series comparisons.

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 a usage scenario — needing search interest over time — but doesn't explicitly say when to choose this over siblings. There are no exclusions or alternative recommendations. The 1-5 keyword limit gives a partial constraint, but won't guide an agent to prefer compare_keywords 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?

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?

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that 'rising' includes % growth and is_breakout (>5000%), which is useful, but it does not cover other behaviors such as how 'top' queries are determined, pagination, error handling, or effect of parameters like geo or timeframe. The description provides some transparency but leaves major behavioral aspects undisclosed.

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 concise (two sentences) and well-structured, with the core purpose front-loaded. There is minimal fluff, though the phrase 'best single source of fresh blog angles' is subjective and could be seen as marketing rather than factual. Overall, it's efficient and easy to scan.

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 the tool has 6 parameters and no schema descriptions, the description is incomplete. An output schema exists to cover return values, but the description's lack of parameter explanation and limited behavioral context leaves significant gaps. It does not convey enough for an agent to understand how to shape queries or interpret results beyond the basic keyword. The description is not sufficient for a tool of this complexity.

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 description does not explain any of the 6 parameters except referencing 'keyword' in the first sentence. It offers no guidance on what 'geo', 'gprop', 'limit', 'category', or 'timeframe' mean or how they affect results. The description fails to compensate for the missing schema descriptions, leaving the agent to guess parameter 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 returns 'Top and rising search queries related to a keyword,' which specifies the verb (returns), the resource (search queries), and the scope (related to a keyword). It differentiates from sibling 'related_topics' by explicitly saying 'search queries' rather than topics, and the mention of 'rising' with % growth is a distinct feature. The use case 'best single source of fresh blog angles' adds specificity without ambiguity.

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 a usage context ('best single source of fresh blog angles') but does not explicitly compare to alternatives or state when not to use it. It implies use for content ideation but leaves the agent to infer when to choose this over siblings like 'suggest_keywords' or 'related_topics'. No exclusions or alternative routing is provided, so it's minimally adequate but not fully guiding.

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?

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?

With no annotations, the description carries the disclosure burden. It reveals the ~24h freshness window, geographic scoping, approximate traffic, and linked headlines. It does not cover data caveats or response behavior in depth, but provides a reasonable baseline.

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 tight sentences front-load the core behavior, scope, and output contents, followed by a practical use case. Every sentence adds value and there is 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 read-oriented tool with an output schema and optional parameters, the description supplies enough context: time range, geo scope, output elements, and intended use. Minor gaps remain around exact geo format and max_articles semantics, but these are not blocking.

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 clarifies that geo refers to a country or US state and hints at max_articles through 'linked news headlines', but it never explicitly ties max_articles to the number of headlines returned.

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 identifies the tool as returning real-time trending searches for a country or US state, with approximate traffic and linked news headlines. This distinguishes it from sibling tools like interest_over_time or related_queries, though it does not explicitly name an alternative.

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' gives a clear, actionable use case and implies the tool is for time-sensitive, content-relevant trend discovery. It does not mention exclusions or alternatives, but the context is sufficient for basic routing.

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