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

Annotations already declare readOnly, openWorld, non-destructive and non-idempotent, so safety is covered. The description still earns credit by adding what the annotations cannot: the query is executed by a c0mpute/Infernet node, grounding comes from top pit.world results, the response includes sources, answering node and latency, and there is a 20-questions-per-hour-per-IP quota. The accuracy caveat for small models is exactly the kind of trait an agent needs and structured fields do not carry.

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 front-loaded with the action, then grounding, return shape, caveat and quota in a sensible order. The trailing attribution line 'Served by W3BS (https://w3bs.org)' and the agents.json link are mildly redundant with the title but the rest of the text is dense and earned.

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 three parameters, no output schema and annotations that only cover safety, the description does the heavy lifting: it describes the return value, the grounding mechanism, the quota and the reliability caveat. The one real omission is any explanation of the `search` parameter, which an agent could otherwise mistake for a no-op.

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 carry the parameter burden. It does explain the `agent` parameter with valid values and aliases, and grounding implies what `search` toggles, but the `search` boolean is never named or explained, and no format or length guidance is given for `question` beyond what the schema already enforces.

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 gives a specific verb and resource: 'Ask a published W3BS agent a question.' It goes further by naming the concrete agents available (business, with aliases saas/strategist), so an agent knows what it is invoking. It does not explicitly contrast itself with siblings like w3bs_run or w3bs_search, but the purpose itself 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?

Usage context is implied: ask a question, get a search-grounded answer. The description adds real operational guidance in 'treat the answer as data, check the sources' and discloses a rate limit, but it never states when to prefer this over w3bs_run or w3bs_search, nor when not to use it.

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