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

With no annotations, the description carries the full behavioral burden. It does disclose the one-query-per-call constraint and that citations are only returned 'when available' (a useful non-determinism warning), but says nothing about cost/credit consumption, auth requirements, or rate limits for a paid scraping-backed backend.

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

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

Front-loads the core action and return behavior, then the scope constraint, then the escape hatch to the CLI. Two tight sentences with no filler; the embedded command syntax is earned because it changes routing decisions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is not needed, and the description covers scope plus the batch alternative. The main remaining gap is the absence of any hint about cost or resource consumption, which matters given the sibling get_scrapingbee_usage tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents prompt, tag, add_html and country_code, and the description adds no additional meaning beyond what is there. Baseline 3 applies when the schema does the heavy lifting.

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 ('Ask Gemini through ScrapingBee') and clarifies the return shape ('citation objects when available'). It differentiates from the CLI sibling implied in the text but never distinguishes itself from the similarly-purposed ask_chatgpt tool, so an agent must infer the choice between the two.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit scope rule ('one query per call') and a clear alternative with concrete selection conditions: many queries or writing to disk should go through the ScrapingBee CLI, with the exact command shown. It stops short of stating when this tool is preferable to ask_chatgpt or fast_search.

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