bing_keyword

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value beyond them: the tool is not site-scoped, empty results carry an empty_response label that must not be read as 'no problems found', and untrusted fields must be treated as data. What is missing is any note on auth/permission requirements or rate limits, so a 4 rather than a 5.

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

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

The core purpose is front-loaded in the first sentence, followed by usage routing and then critical reporting caveats. Every sentence carries distinct operational information 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?

No output schema exists, so the description takes on return-value responsibility and does so by explaining the empty_response label and its interpretation. It also warns about untrusted fields, covering the safety dimension an agent needs before acting on results.

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 carry parameter meaning, and it only maps them loosely ('one query, country and language, totalled over a date range') without format guidance such as country/language code conventions or date format. It clarifies the aggregation semantics but leaves the actual input formats undocumented.

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

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

States a specific verb and resource ('Read Bing keyword impressions') with explicit scope (one query/country/language, totalled over a date range). It also disambiguates from siblings by naming bing_keyword_stats and bing_traffic_query as the wrong tools for adjacent needs.

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 when-to-use ('user asks how much search demand a keyword had in a given period'), when-not-to-use, and named alternatives for each excluded case. Two distinct exclusion scenarios are routed to the correct sibling tools.

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