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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds valuable context beyond annotations: it requires an external API key from Bing Webmaster Tools and emphasizes 'real' impressions, which distinguishes observed data from estimates. This is meaningful behavioral 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 description is a single concise sentence that front-loads the core purpose and immediately states the one critical prerequisite. There is no redundancy or 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 simple read-only lookup with an output schema and well-documented parameters, the description includes the main missing runtime context: the API key requirement and the real-data nature of the result. It does not cover error handling or rate limits, but these are not essential for basic invocation given the existing structured metadata.

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 75%, with days, country, and language already documented. The description reinforces 'one keyword' and 'last N days', which maps to keyword and days, but does not add new semantic detail for the parameters. This is adequate given the schema's existing descriptions.

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 metric ('Real Bing search impressions'), the scope ('one keyword'), and the time window ('last N days'). It is specific enough to understand the tool's purpose, but it does not explicitly contrast itself with siblings like bing_keyword_history or estimate_volumes.

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 a prerequisite ('Needs FREE_SEO_BING_API_KEY') but gives no guidance on when to choose this tool over alternatives such as estimate_volumes, bing_related_keywords, or bing_keyword_history. There is no explicit when-to-use or when-not-to-use information.

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, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds valuable context beyond annotations: it specifies the data granularity (weekly), the scope (one keyword), and the intended use (seasonality). It also discloses the external dependency on FREE_SEO_BING_API_KEY, which is important for the agent to know before invoking. This is meaningful behavioral context that annotations don't provide.

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 sentence that packs essential information: the data type (weekly impressions), scope (one keyword), purpose (seasonality), and a prerequisite (API key). Every word earns its place, and the most important information is front-loaded. No fluff or repetition of schema details.

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 documented elsewhere. The description covers the core purpose, the data granularity, and the API key requirement. The only minor gap is that it doesn't explain what the output looks like (e.g., a time series of impressions), but the output schema likely covers that. For a read-only, idempotent tool with a simple parameter set, this is nearly 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?

Schema description coverage is 67%: keyword has no description, while country and language have descriptions. The description adds context that the tool is for one keyword and weekly history, which helps understand the keyword parameter's role. However, it doesn't add details about the country/language parameters beyond what the schema already provides, and it doesn't clarify the expected format or constraints for keyword. Baseline 3 is appropriate since the schema covers most parameters and the description adds some context.

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: 'Weekly Bing impression history for one keyword (seasonality).' This clearly identifies what the tool does and its purpose. It is distinguishable from siblings like bing_keyword and bing_related_keywords because it focuses on historical impression trends over time, though it doesn't explicitly name those 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 implies usage context: it is for seasonality analysis of a single keyword, which suggests when to use it (when you need historical Bing impression trends). It also mentions the required API key, which is a prerequisite. However, it doesn't explicitly state when not to use it or name alternative tools for related but different needs, such as bing_keyword for current metrics or trends_compare for comparisons.

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?

Beyond the readOnly/idempotent annotations, it uniquely discloses the data source, the time window, sorting behavior, and the required FREE_SEO_BING_API_KEY. This is valuable operational context; only minor omissions such as result limits keep it from being 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 short sentences, front-loaded with the core behavior and output ordering. The word 'free' appears twice ('free source' and 'FREE_SEO_BING_API_KEY (free)'), a small redundancy that keeps it from a perfect score.

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 no extra explanation; the description covers the data source, temporal range, sorting, and authentication. It is nearly complete for a simple read-only lookup, though it does not address any rate-limit or pagination behavior.

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 description ties 'phrase' to the required keyword parameter and 'last N days' to days, which helps since keyword has no schema description. However, it adds nothing beyond the schema for country or language, and coverage is only moderate (75%).

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 says the tool returns keywords related to a phrase, enriched with real Bing impressions and sorted by impressions. It lacks an explicit verb ('Keywords...' instead of 'Gets keywords...'), and it implies differentiation from sibling keyword tools through the 'free... with numbers' angle rather than naming 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?

It conveys an implied use case—when you need free Bing keyword ideas backed by real impression counts—but it never states when not to use it or which sibling (e.g., suggest, bing_keyword) would be an alternative. With 15 sibling tools, more explicit routing would help.

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 cover readOnly, idempotent, and openWorld hints. The description adds valuable behavioral details beyond that: the 4-keyword batching strategy, the Google Trends ratio plus Bing-base computation, and the explicit caveat that results are 'rough estimates, not exact counts.' No contradiction 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?

Three dense sentences deliver the method, the base-value logic, the output schema highlights, and the key field guidance. Every sentence adds information, and the most important caveat ('rough estimates') is prominently included.

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 10 parameters and a non-trivial estimation algorithm, the description covers the essential computation, output fields, and uncertainty. The output schema exists, so return-value details need not be repeated. It lacks minor clarifications such as regional matching or timeout behavior, but 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 coverage is only 50%, so the description needs to compensate. It explains the meaning and relationship of anchor, anchor_volume, engine_multiplier, and Bing impressions, which is the core algorithm. It does not elaborate on geo, timeframe, bing_language, or threshold params, but those are reasonably clear from the schema and the described tier output.

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: 'Estimate monthly search volume for many keywords.' It clearly distinguishes this estimation tool from the sibling expansion, suggestion, and trends-comparison tools by describing the anchor-based methodology and output (volume, tier, confidence, method).

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 context for when to use the tool: when you need approximate monthly volumes rather than exact counts. It also provides concrete selection guidance ('Pick an anchor of similar popularity whose volume you know'), but it does not explicitly name alternatives or state when not to use this tool.

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 cover readOnlyHint, idempotentHint, and openWorldHint. The description adds useful behavioral details beyond those: it returns unique phrases ranked by a popularity score, includes occurrence counts, defaults sources to ['google'], and reports progress. No contradiction with annotations exists.

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 with the core behavior, followed by return characteristics and defaults. It earns its sentences, though the final two clauses could be better integrated and slightly more 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?

The presence of an output schema reduces the need to describe return values, and annotations cover safety and idempotency. However, the description still leaves gaps around how the alphabet is determined, what gl/hl control, and how to choose this tool among similar expand/suggest 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 0%, so the description carries the burden of explaining parameters. It only clarifies that sources defaults to ['google']. The meaning of keyword, gl, and hl is left implicit or unexplained, and 'per alphabet' is not tied to any parameter.

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 ('Expand a seed in breadth') and defines the resource (the seed plus alphabet suffixes). It is clear what the tool does and roughly how it differs from general suggestion tools, though it does not explicitly distinguish itself from expand_questions or expand_multilingual.

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?

No explicit guidance is given for when to use this tool versus its siblings. The phrase 'expand a seed in breadth' implies a use case, but there are no stated exclusions, alternatives, or conditions that would help an agent choose this over expand_questions or expand_multilingual.

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, openWorldHint, and idempotentHint, so the safety profile is known. The description adds valuable behavioral detail: it discloses that a failing locale reports its error field and does not affect other locales, which is useful for handling partial failures. This goes beyond 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?

The description is compact: two sentences plus a focused note on locales. It front-loads the primary purpose and provides essential parameter details without unnecessary wording. Every sentence contributes to understanding tool behavior.

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 gives the core behavior, locale syntax, defaults, and error handling. Since an output schema exists, return values are not needed. It does not mention the 'source' parameter, but the schema's enum clarifies its options. For a tool with moderate complexity, this is nearly 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?

With 0% schema description coverage, the description must compensate. It thoroughly explains the 'locales' parameter with format and default values, and 'keyword' is implied as the seed. However, it does not add any meaning for the 'source' parameter, which has an enum but no additional guidance. The description covers only one of three parameters substantively, so it only partially compensates for the schema 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 states a specific action — "Run one seed through autocomplete" — and a distinctive scope: "several locales at once." This clearly distinguishes it from sibling expand tools like expand_alphabet or expand_questions, and from suggest, which likely handles a single locale.

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 when to use it: when you need autocomplete expansion across multiple locales simultaneously. It provides default locales and clarifies that a failing locale doesn't break others, giving practical context. However, it does not explicitly compare with alternatives or state when not to use it, so it's a step below the explicit routing seen in the best examples.

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, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral context: it reports progress, defaults sources to ['google'], and explains the output is scored phrases similar to 'People also ask'. 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?

The description is compact and front-loaded with the core action. The second sentence adds useful context about intent and scoring, and the third sentence covers defaults and progress reporting. No wasted words, though the structure could be slightly clearer by separating the default from the behavioral notes.

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 and idempotence, and the output schema exists, the description covers the key behavioral aspects: what it does, how it scores, default sources, and progress reporting. It doesn't explain the exact output structure, but the output schema handles that. Minor gap: no mention of how 'gl'/'hl' affect the question prefixes, but this is not critical.

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 'sources' default and the general role of the keyword, but it does not explain 'gl', 'hl', or the exact format of 'sources' beyond the default. The description adds some meaning (e.g., language prefixes, scoring) but leaves several parameters to be inferred from the schema alone.

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 ('expand') and resource ('a seed with question prefixes'), and clarifies the language dimension. It also names a sibling ('expand_alphabet') for comparison, which helps distinguish it from similar expansion tools. However, it doesn't explicitly contrast with expand_multilingual, another close sibling, so differentiation is partial.

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 context: it surfaces informational intent similar to 'People also ask', and notes that phrases are scored like expand_alphabet. It also states the default sources. It does not explicitly say when NOT to use this tool or name alternatives like expand_multilingual, but the context is strong enough for an agent to infer appropriate use.

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 idempotentHint=true, so the description need not repeat safety traits. It adds value by clarifying the operation is a filtered retrieval of saved keywords, but gives no additional behavior such as pagination, ordering, or empty-result handling. No contradiction 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?

A single sentence that front-loads the core action and resource, then appends the optional filter conditions. Every word earns its place with no redundant 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-only load operation with an output schema and safety annotations, the description covers purpose and filters adequately. The only material gap is explicit usage guidance versus alternative keyword-generation/save tools, which is not severe enough to lower the score further.

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 only 50% (tier and cluster have descriptions; project and lang do not), so the description partially compensates by identifying project/lang as the scoping keys and tier/cluster as optional filters. It adds relational meaning but no format or value details beyond the schema.

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

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

The description uses a specific verb ('Load') with a clear resource ('saved keywords for a project and language') and specifies optional filters. This differentiates it from key siblings like keywords_save (which saves rather than loads) and suggest/expand tools (which generate rather than retrieve stored data).

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 the tool is for retrieving previously saved keywords, so an agent can infer when to use it rather than keywords_save or suggestion tools. However, it offers no explicit when-to-use/when-not-to-use guidance or named alternatives, leaving some routing 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 description goes well beyond the annotations by explaining deduplication by normalized phrase, case/whitespace insensitivity, overwrite behavior for non-empty fields, and source merging. This gives the agent a clear model of what happens on conflict, which is critical for a write operation.

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 action and path are front-loaded, followed immediately by the deduplication and overwrite rules. 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?

The description is sufficient for a moderately complex merge operation, especially since an output schema exists. It covers destination, conflict resolution, and source handling. It could optionally mention when to use this versus keywords_load, but that is not essential for invoking the tool 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 67%, and the description adds meaningful semantics by explaining that project and lang form the CSV path and that rows are merged with deduplication and field-overwrite behavior. This clarifies the 'rows' parameter more than the raw schema does.

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 ('Merge') and resource ('keyword rows into the project's CSV store'), with an explicit path template. This clearly distinguishes it from sibling read/expansion tools and from keywords_load, which likely reads the same store.

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: call this when you want to save or merge keyword rows into the project CSV. However, it does not explicitly say when not to use it or mention alternatives like keywords_load for reading, so usage guidance is only implied rather than directly stated.

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, idempotentHint, and openWorldHint, and the description's 'Fetch' is consistent with those. The description adds little behavioral nuance beyond processing one page and listing extracted content pieces; it does not discuss failure modes, external network effects, or restrictions.

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 sentence, front-loaded with the action and followed by a precise list of outputs. Every word adds information, and there is no redundant restatement of the tool name or 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?

The tool is low complexity: one required URL, read-only and idempotent annotations, and an output schema exist. The description provides enough selection and invocation context for an agent to call the tool correctly; failure-mode details are not essential at 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 coverage for the URL parameter is 0%, so the description compensates by defining the parameter as 'one page' and implying it should be an HTML page from which title, meta description, and headings can be extracted. It does not specify URL format or public-access constraints, but with a single required parameter this is a minor 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?

Opens with a specific verb and resource ('Fetch one page') and enumerates an exact return contract: title, meta description, H1-H3 headings, and word count. This distinguishes it from the keyword- and sitemap-oriented sibling tools, none of which provide a per-page content outline.

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?

Clearly frames the tool as a single-page content-outline operation, so an agent knows to use it when it needs on-page title, meta description, headings, or word count. It does not explicitly name alternatives or exclusions, but the singular 'one page' separates it from bulk sitemap and keyword 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, openWorldHint, and idempotentHint, covering the tool's safety and idempotency profile. The description adds the return field list (title, subreddit, score, comment count, URL, snippet), which is useful behavioral context beyond annotations. However, it does not disclose rate limits, pagination, or any potential side effects, and since annotations already cover the main behavioral traits, the description adds only marginal value.

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 and well-structured. It leads with the primary purpose in the first sentence, then lists the return fields in the second. Every sentence adds value, and there is no redundant information. It is appropriately short for a search tool with a clear function.

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 and an output schema, the description is minimal. It does not explain when to use it, how to construct effective queries, or how parameters interact. While the output schema likely describes return fields, the description lacks guidance on parameter usage and alternative selection. The tool's openWorldHint suggests external data, but the description does not elaborate on limitations or expectations. Overall, it is not complete enough for an agent to use confidently without additional schema inspection.

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 only 20% (only 'subreddit' has a description in the schema). The tool description does not explain any parameter meanings, such as what 'query' represents, how 'sort' affects results, or what 'time' filtering does. Since coverage is low, the description should compensate, but it provides zero parameter guidance. An agent would have to rely on the schema's enum values and default values without understanding the 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 purpose: searching Reddit threads to understand buyer language. It specifies the resource (Reddit threads) and the intent (hear how real buyers phrase questions). It also lists the returned fields, which clarifies the output. However, it does not explicitly differentiate from sibling tools, though the siblings are obviously different in scope, so it's not a major issue.

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 no guidance on when to use this tool versus the many sibling tools. It does not mention alternative tools or conditions for selection. An agent is left to infer usage from the name and description alone, with no explicit context about when Reddit search is the right choice over suggest, trends, or expand 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?

Beyond the annotations (readOnly, openWorld, idempotent), the description discloses the discovery process (robots.txt, fallback to /sitemap.xml), recursive following of sitemap indexes, and handling of gzipped sitemaps. This gives useful behavioral insight that annotations do not cover.

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 concise sentences with the primary purpose front-loaded and the technical discovery details following. 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?

Given the existence of an output schema and the detailed behavioral description, the tool is well-specified. It could mention failure modes (e.g., no sitemap found) but that's minor.

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 covers site and contains with descriptions; limit lacks a description but has default/max/min. The tool description does not elaborate on any parameters, so it adds no value beyond the schema. With 67% coverage, it's borderline; clarifying limit's effect would have helped.

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 action (List page URLs), the resource (competitor's sitemaps), and the purpose (to map its content structure). This distinguishes it from siblings that focus on keywords, trends, or page outlines.

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 use case (mapping competitor content) but does not explicitly contrast with alternatives or state when not to use. Since no sibling is similar, it's somewhat implied, but lacks explicit 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 indicate read-only, idempotent behavior. The description adds meaningful behavioral detail beyond that: results are ranked, position 0 is the most popular completion, and only one query from one engine is handled at a time. No contradiction 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?

The description is compact and front-loaded: the core purpose appears first, followed only by essential parameter semantics and ranking behavior. Every sentence adds value with no 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 suggestion tool with an output schema and annotations, the description covers the key invocation decisions: source choice, language/country semantics, and result ordering. It could be more explicit about keyword semantics, but nothing critical is missing for correct use.

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?

Despite 0% schema description coverage, the description documents the allowed source enum values and explains hl and gl with examples. The required keyword parameter is only implied as the 'query', which is a minor gap given the tool name and first sentence.

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 clear verb-resource behavior: it returns autocomplete suggestions for one query from one engine, in rank order. This distinguishes it from sibling tools like expand_alphabet and trends_* by scope and output type.

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 when to use the tool: for a single-query, single-engine autocomplete lookup. However, it does not explicitly name alternative tools such as expand_alphabet or expand_questions, nor does it give when-not-to-use guidance, so some selection reasoning is left 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 cover read-only, open-world, and idempotent behavior, lowering the burden. The description adds meaningful behavioral detail: the 0–100 score scale, the sorted ordering, and the conditional output level based on the geo parameter. There is no contradiction 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?

The description is two short sentences. The first sentence states the core purpose, and the second explains the key behavioral variation. No filler words, and the most important 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?

The tool has an output schema, so the return structure is covered. The description covers the main functional behavior and the geo behavior, but could benefit from mentioning the role of the limit parameter or how resolution interacts with geo. Still, overall it is sufficiently complete for a read-only tool with annotations.

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 description adds semantic meaning for the geo parameter beyond the schema by stating that '' returns countries and a country code returns regions. However, the limit parameter has no schema description and is not mentioned in the tool description, so the 50% schema coverage is only partially compensated.

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 geographic regions where a keyword is most searched, using Google Trends data with a 0–100 score and sorted order. It distinguishes itself from siblings like trends_compare or trends_related by focusing specifically on regional popularity, and it clarifies the geo-dependent output level.

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 explains the two modes – country-level when geo='' and region-level when a country code is provided – which gives clear usage context. However, it does not explicitly mention alternatives or when not to use it, leaving the choice to inference rather than stating exclusions.

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, idempotentHint, and openWorldHint. The description adds meaningful behavioral context beyond those: the 0-100 relative scale, the returned metrics (time series, mean, peak), and the explicit note that interest is relative rather than absolute. No contradiction 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 sentences with no filler. The first sentence states the action, scope, and output; the second clarifies the scale and the relative-versus-absolute limitation. Everything included 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 output schema, annotations, and simple three-parameter input, the description covers the essential invocation context: what the tool compares, what it returns, and the key interpretational caveat. No critical operational detail appears 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 67%, with geo and timeframe already documented. The description adds little per-parameter meaning beyond the schema: it clarifies that keywords are compared, but 'up to 5' is already encoded in maxItems, and no additional guidance is given for keyword formatting, geo values, or timeframe syntax.

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'), names the resource ('Google Trends'), and defines the scope ('up to 5 keywords'). It also states the output ('time series, mean and peak') and the key limitation ('relative interest only, not absolute volume'), which clearly distinguishes it from volume-oriented siblings like estimate_volumes.

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 context for when to use the tool: comparing up to 5 keywords on a shared scale. It explicitly excludes absolute-volume use cases, which is a useful when-not signal, though it does not name alternative tools such as estimate_volumes or trends_related.

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, openWorldHint, and idempotentHint, covering safety. The description adds value by disclosing the output structure (top scores 0-100 and rising growth percentage), which is not apparent from annotations alone. It does not contradict any annotation and provides useful behavioral context about the return format.

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, both meaningful and front-loaded. The first sentence states the core functionality and output format, the second provides a concrete use case. There is zero waste and no repetition of schema 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?

The tool has an output schema (indicated by 'has output schema: true'), so the description need not detail return structure. Annotations cover safety. The description covers the essential behavioral aspects (output types) and the use case, making it adequate for a tool of this simplicity. Minor gaps like rate limits or error handling are not critical given the tool's low complexity and the presence of structured fields.

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 50% (geo and timeframe have descriptions, but keyword and limit do not). The description clarifies that the tool operates on a single keyword, which adds semantic meaning to the 'keyword' parameter beyond the bare schema. However, it does not explain the 'limit' parameter or any syntax details, leaving gaps that the schema does not fill. The added value is modest but non-trivial.

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 retrieves Google Trends related queries for a single keyword, explicitly listing the two output types ('top' and 'rising') and their meanings. It distinguishes itself from siblings like trends_compare (which handles multiple keywords) and suggest (which generates keyword ideas), making its purpose 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 a clear use case ('Good for finding new keyword ideas') but does not explicitly state when to prefer this over alternatives or mention any exclusions. It implies usage for keyword ideation but provides no guidance on when not to use it or how it compares to sibling tools like expand_alphabet or trends_by_region.

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