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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, and the description is consistent with those. It adds useful behavioral context beyond annotations by explaining that the tool retrieves article text or metadata and can summarize a given URL, clarifying what the operation actually performs.

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 with no filler. The core operation is front-loaded, and the exclusionary guidance is placed right after the primary use case.

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, combined with full schema coverage, a rich set of annotations, and an output schema, gives an agent everything needed to invoke the tool correctly. The only real decision point—discovery versus single-article retrieval—is addressed explicitly.

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 100%, so the schema already documents all parameters. The description adds context around the URL being a specific article URL rather than a discovery query, but it does not materially enrich the parameter semantics beyond what the schema provides.

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: download and parse one specific news article using an article URL. It also explicitly contrasts itself with the discovery-focused sibling tools, making its scope 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?

It clearly states when to use the tool (when you already have an article URL) and when not to use it ('do not use it for discovery - use the news search tools instead'). This gives an agent an explicit selection rule relative to the sibling tools.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context about pagination ('bounded page', 'offset/limit to page through broader results') and the warning not to guess IDs. This goes beyond the annotations without contradicting them.

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, zero waste. The primary purpose is front-loaded, and the usage guidance follows immediately. The warning 'do not guess category IDs' is a valuable addition that earns its place. No redundant phrasing.

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 is simple with three optional parameters and a known output schema (implied). The description covers purpose, usage, and a critical warning. For a straightforward lookup tool, nothing essential is missing. An agent can correctly invoke it with the provided information.

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 100%, so all three parameters are already documented. The description reiterates that query is for name matching and offset/limit for paging, which adds slight contextual meaning but does not introduce new semantics beyond the schema. The baseline of 3 is appropriate given full schema coverage.

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 a bounded page of Google Trends category IDs and names, explicitly linking them to the cat parameter of trend tools. It distinguishes itself from sibling tools by focusing solely on category data, and the verb 'Return' plus resource specification is 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 gives explicit guidance on when to use query vs offset/limit for paging, and warns against guessing category IDs, implying this tool should be used to obtain valid IDs. It lacks explicit exclusion of alternatives, but the context of 'for use in the cat parameter' clearly defines the intended use case.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds the read-only computation framing and the 'known keywords' constraint, which is useful but not extensive. It doesn't address behaviors like handling unknown keywords or data availability, but with annotations carrying the safety burden, this is adequate.

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, zero waste. The core purpose is front-loaded and the routing guidance is delivered in a compact conditional. 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?

With an output schema present, the description need not explain return values. It covers purpose, routing, and the percentage-growth goal; the schema covers parameters and constraints (e.g., 1-5 keywords). Nothing an agent needs to invoke this correctly is 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 100%, so all four parameters are already documented. The description adds only the contextual link that percent_growth is the tool's output goal, which maps to the percent_growth parameter but adds no format or syntax details beyond the schema. Baseline 3 is appropriate.

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-resource pair ('Estimate momentum for one or more known keywords across requested growth windows') and explicitly differentiates from get_trends by stating the percentage-growth focus. An agent can distinguish this tool from its 15 siblings without opening schemas.

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?

Provides explicit routing: 'Use this when percentage growth is the goal; use get_trends when the user needs the underlying historical time series.' This names the alternative and the condition that selects between them, leaving nothing to inference.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the geographic resolution scope and the 'known keywords' nuance, which is useful but not extensive. It doesn't describe return format or pagination, but that's covered by the output schema and annotations.

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 with zero wasted words. The core purpose is front-loaded, and the alternative tool is named in the second sentence. This is an exemplary concise structure.

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 7 parameters but the schema fully describes each, and an output schema exists so return values don't need to be explained. The description covers the primary usage distinction (geographic vs. time-based) and the resolution options. It is complete for an agent to call correctly; the only minor gap is not stating that keywords must be exact known terms, but that is implied by 'known keywords' and the schema's string type.

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 100%, so all parameters already have clear descriptions. The description mentions 'known keywords' and resolution levels, but these are already implied in the schema. With full schema coverage, the baseline of 3 is appropriate; the description adds minimal extra meaning beyond what the schema provides.

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 ('Return'), a resource ('Google Trends interest'), and the scope ('geographic ... at country, region, city, or DMA resolution'). It explicitly differentiates from the sibling get_trends by noting that get_trends handles interest over time, so an agent can immediately tell this tool apart.

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: 'Use this to compare where demand is strongest; use get_trends for interest over time instead.' This tells the agent when to use this tool and when to use an alternative, leaving nothing to inference.

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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the context of searching recent Google News, but little additional runtime behavior beyond that. It doesn't describe summarization/full_data defaults, though schema handles parameter details.

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 sentences long, leads with the core purpose, and uses the second sentence only to route to alternatives. Every clause adds value.

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 comprehensive parameter descriptions, an output schema, and read-only annotations, the definition is fully sufficient. It also positions the tool among siblings, so an agent has everything needed to select and invoke 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 description coverage is 100%, so the schema already documents all five parameters, including defaults and constraints. The description reinforces that the keyword is free-form and ad-hoc, but no extra semantics are needed.

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 the verb 'Find' and a clear resource, 'recent Google News articles for a free-form keyword or phrase', and immediately distinguishes itself from get_news_by_topic and get_news_by_site. An agent can tell exactly what this tool does relative to its 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?

It explicitly scopes the tool to 'ad-hoc subject searches' and names the alternative tools for predefined topics and single-publisher searches. This is direct when-to-use guidance with alternatives.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about the geographic scoping of the search, but does not disclose additional behavioral details such as result ordering, default summarization behavior, or external API dependencies. This is acceptable 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 with no filler. The core purpose is front-loaded, and the comparative usage guidance is delivered economically. 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?

With annotations covering safety, a fully described schema, and an output schema present, the description does everything needed for selection and invocation. It states what the tool doesaintstrikes, when to use it, and the main alternative, so nothing critical is 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 100%, so the parameters are already well documented in the input schema. The description does not add new parameter-level meaning beyond stating that location is geographic, which the schema also conveys. Baseline 3 is appropriate.

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 and resource: 'Find recent Google News articles' and narrows scope to 'place-focused location such as a city, state, or country.' It explicitly contrasts with get_news_by_keyword, helping an agent distinguish it from 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 description gives direct when-to-use guidance: 'Use this when geography is the primary filter.' It names the alternative tool for general subject searches, get_news_by_keyword, leaving no ambiguity about the main routing decision.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat safety. The description adds no extra behavioral context like pagination or rate limits, but for a read-only tool with output schema, it doesn't need to. The 'recent' qualifier and 'one publisher domain' scope are more purpose than 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?

Two sentences, zero filler. The main purpose is front-loaded, and the alternative tool is named in the next clause.

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?

With a full output schema, complete parameter descriptions, and annotations covering safety, the description leaves nothing critical missing. It names the primary alternative for differentiation, and the domain-scope phrasing inherently distinguishes it from location/topic siblings.

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 100%, so the schema fully documents the parameters. The description adds no parameter-specific meaning beyond the schema, yielding the baseline score of 3.

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: 'Find recent Google News articles from one publisher domain.' It also names the sibling it is not: 'use get_news_by_keyword for cross-publisher subject search,' which differentiates it from 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?

Explicitly says when to use: 'when the user wants source-specific coverage' and which alternative to choose: 'use get_news_by_keyword for cross-publisher subject search.' This provides clear decision 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context about recency and predefined categories, but does not disclose behaviors such as how invalid or unknown topic values are handled. With annotation coverage present, this is adequate but not exceptional.

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 with no filler: the first states what the tool does, and the second provides usage routing to the sibling tool. The information is front-loaded and 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?

Given the annotations, complete input schema, and output schema, the definition is largely sufficient. The only notable gap is that it does not point the agent to get_categories for discovering valid predefined topic values, though the examples and 'predefined' wording partially compensate.

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 100%, so the parameters are already documented. The description adds meaningful semantic value to the required 'topic' parameter by clarifying it must be a predefined category and supplying concrete examples, which goes beyond the schema's generic 'Topic to search for articles.'

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 verb ('Find') and resource ('recent Google News articles from a predefined Google News topic category'), and it explicitly distinguishes the tool from get_news_by_keyword. The examples BUSINESS, TECHNOLOGY, and SPORTS make the purpose immediately recognizable.

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 provides explicit when-to-use guidance: 'Use this for topic category browsing' and names the exact alternative for free-form queries, get_news_by_keyword. This leaves no ambiguity about which tool fits which scenario.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the context that results are current trending keywords and that rank order is the key feature, but does not reveal additional behavior beyond what annotations and schema already imply. No contradiction is present.

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, no filler, with the core behavior front-loaded and the sibling differentiation in the second sentence. 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 tool has an output schema, all parameters are optional and documented, and the description provides enough context for selection and invocation. The explicit sibling guidance completes the picture for an agent deciding which trends tool to call.

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 100%, so the schema fully documents all four parameters. The description adds minimal parameter-level meaning beyond the schema, only reinforcing that ranking can be by growth or volume, which matches the sort enum. Baseline 3 is appropriate.

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 action and resource: 'Return currently trending keywords ranked by week-over-week growth or volume.' It also distinguishes the tool from get_top_trends and get_trends, so an agent can tell them apart without inspecting schemas.

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 says 'Use this when explicit ranked order matters' and names the alternatives: get_top_trends for a simpler current feed and get_trends for historical series. This is clear routing guidance with no ambiguity.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context: it specifies that the output consists of 'literal' search queries and distinguishes 'top and rising' from other query types, which helps the agent understand what kind of data to expect. It does not mention pagination or result limits, but that is a minor gap given the annotations.

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 with zero redundancy. The first sentence front-loads the purpose and output type, and the second immediately gives usage guidance and alternatives. Every word contributes value.

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 a simple signature (5 params, 1 required) and an output schema exists (indicated by has output schema: true), so the description does not need to explain return values. Annotations cover safety and openness. The description provides sufficient context for an agent to call it correctly without additional information.

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 100%, so every parameter is already documented in the input schema. The description adds no extra meaning about parameters—only the term 'seed keyword' which maps to the 'keyword' property but provides no additional format or constraint details. Baseline 3 is appropriate.

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 verb 'return' and the resource 'top and rising literal search queries related to one seed keyword'. It also explicitly names sibling tools (get_related_topics, get_suggestions) and differentiates its purpose from them, so an agent can select it 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?

It explicitly states when to use this tool ('for query expansion') and provides clear alternatives with conditions ('use get_related_topics for topic entities or get_suggestions for autocomplete candidates'). This is direct, unambiguous 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about the result nature ('top and rising' topic entities), but it does not disclose other behavioral traits such as whether results are limited, exhaustive, or paginated. With annotations covering safety, this is adequate but not exceptional.

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 efficient sentences with no filler. The core purpose is front-loaded, and the alternative-tool routing is placed in the second sentence. Every word contributes to selection or invocation.

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 annotations cover safety, the schema fully documents all parameters, and an output schema exists, the description is complete for an agent to call this tool correctly. It also provides the necessary sibling differentiation without requiring the agent to inspect other tool definitions.

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 100%, so the schema documents all five parameters. The description adds meaningful value by clarifying that the tool accepts 'one seed keyword', a constraint not explicitly stated in the schema's parameter descriptions. This helps agents avoid passing multiple keywords or a query-style string.

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 ('Return') and a precise resource ('Google Trends topic entities' related to a seed keyword), and it explicitly distinguishes itself from get_related_queries. An agent can immediately understand what this tool does and how it differs from the closest sibling.

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 provides an explicit usage directive: use this tool for entity or topic expansion and use get_related_queries for literal search queries. This directly guides tool selection against the most relevant alternative, leaving no ambiguity.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds the 'lightweight' qualifier, which hints at performance characteristics but does not disclose other behavioral traits like rate limits, pagination, or response format. Since annotations are present, the burden is lower, and the description provides minimal added value beyond them.

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 sentences, each earning its place. The primary purpose is front-loaded, followed by usage guidance that references a sibling tool. There is no repetition or extraneous information, making it highly concise and well-structured.

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's simplicity (2 parameters, one required), the presence of an output schema, and annotations covering safety, the description is largely complete. It explains the tool's function and when to use it over get_related_queries. A minor gap is that it does not explicitly state that the output is a list of suggestions, but the output schema and tool name make this evident. Overall, an agent has sufficient context 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 description coverage is 100%, so the schema fully documents both parameters (keyword and language). The description mentions 'seed keyword' but that is essentially the same as the keyword parameter, adding no new syntax, formatting, or semantic details beyond the schema. Thus, the description does not significantly enhance parameter understanding.

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 action ('Return Google Trends autocomplete suggestions') and identifies the resource ('seed keyword'). It also distinguishes itself from the sibling tool get_related_queries by referencing its purpose and scope, making it clear what this tool does and what it does not.

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 provides when-to-use ('lightweight autocomplete or entity candidates') and when-to-use-alternative ('use get_related_queries when you need top or rising demand signals'). This directly routes the agent to the correct tool based on the need, with a 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?

Annotations already provide readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds that results come from Google News and are unfiltered, but it does not describe details like result aggregation, freshness, or the relationship between full_data and summarize. With annotations present, this is 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 with no filler. The core behavior is front-loaded, and the usage guidance adds meaningful routing information without redundancy.

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 news tool with a complete input schema, an output schema, and strong annotations, the description covers the essential context: what it returns, when to use it, and which sibling to use instead when a filter is present. Nothing critical is missing for an agent to invoke 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 description coverage is 100%, so the schema documents all four parameters. The description does not add parameter-specific semantics, but it does clarify the absence of a keyword/topic seed, which helps explain why no such parameter exists. Baseline 3 is appropriate.

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: 'Return general headline and top-news stories from Google News without a keyword or topic seed.' It clearly distinguishes this from the sibling keyword, location, topic, and site news tools by emphasizing the lack of filters.

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 explicitly says to use this tool for 'a broad news snapshot' and to use the keyword, location, topic, or site tools when the user gives a filter. This provides direct when-to-use and when-not-to-use guidance with named alternatives.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations: the data source (Google Trends RSS), the feed type (current top or daily), and that related news is included where available. It does not discuss rate limits or freshness, but for a read-only RSS tool this is a minor gap.

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 with no filler. The first sentence front-loads the purpose and key qualifiers (bounded, current, Google Trends RSS, related news), and the second sentence routes to the alternative when appropriate. 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?

With a full input schema, an output schema, and annotations covering read-only/open-world behavior, the description is largely complete. It adds source, feed type, related-news detail, and routing to get_ranked_trends. A minor gap is that it does not clarify how this relates to get_trends or get_trending_terms, but that is not essential given the existing structure and the explicit use-case guidance.

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 100%; all three parameters (geo, type, limit) have descriptive schema entries with defaults and an enum for type. The description adds little parameter-level meaning beyond implying the type choices, so the baseline of 3 is appropriate.

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 action ('Return a bounded current topic discovery feed'), a concrete resource ('Google Trends RSS'), and explicitly names get_ranked_trends as the sibling when ranking by growth or volume matters. An agent can immediately distinguish this from related tools.

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 explicit usage guidance: 'Use this for current top or daily trends' and 'use get_ranked_trends when explicit ranking by growth or volume matters.' This provides both when-to-use and when-not-to-use with a named alternative, leaving little to inference.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'trending now' (time-sensitivity) and 'optionally with related news metadata' (behavior depending on full_data), but does not add rich behavioral context like data freshness, ordering, or potential variability. This matches the baseline for a read-only tool with annotations.

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: the first delivers the core action, the second delivers routing guidance. No filler words; every part earns its place and key information is front-loaded.

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?

With an output schema present, return values need no explanation. The description covers purpose and usage, the schema covers parameter details, and annotations cover safety. Nothing an agent needs to select and invoke this tool correctly is 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 100%, so the schema fully documents both parameters. The description's mention of 'optionally with related news metadata' loosely maps to full_data but adds no detail beyond what the schema already provides for geo (formats and examples) and full_data (related news stories). Baseline 3 is appropriate.

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 ('Return') and resource ('terms that are trending now for a geography'), and clearly distinguishes this tool from get_trends by noting the latter is for historical interest over time. This precisely differentiates from the sibling tools.

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 an explicit usage directive: 'Use this for current trend discovery; use get_trends when the user wants historical interest over time for known keywords.' It names the alternative and the condition that selects between them, leaving no ambiguity.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond annotations by clarifying that values are normalized 0-100 interest scores, not absolute search volume, which is essential for interpreting results correctly.

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 focused sentences with no filler. The primary purpose is stated first, followed by usage context and a direct pointer to the relevant sibling tool. Every sentence 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 the rich input schema, output schema presence, and annotations covering read-only/non-destructive behavior, the description provides all essential decision-making context: what the tool returns, how to interpret the values, and when to use the main alternative. Nothing critical is 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 100%, so the schema already documents all six parameters thoroughly. The description mostly repeats what the schema conveys ('known keywords', 'timeframe', 0-100 values) without adding new parameter-level meaning, so the baseline of 3 is appropriate.

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 ('Return') and resource ('historical Google Trends interest-over-time points') and explicitly contrasts with get_trending_terms, which is about what is trending now. This makes it easy for an agent to distinguish this tool from the many sibling trend-related tools.

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 clear when-to-use guidance: for trajectory and comparisons across a timeframe. It also explicitly names the alternative get_trending_terms for current trending terms, leaving little ambiguity about tool selection.

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