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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile needs no restating. The description adds genuinely new behavior beyond that: the enumerated data sources and the return shape ('a preview and a `ref` for the story'), which matters because no output schema exists. It stops short of a 5 by not covering failure modes (no matching data), result size, or how the returned `ref` is consumed downstream.

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 short sentences with no filler. The source list is compressed into parentheses and the key constraint ('never from memory') plus the return shape are both front-loaded, so an agent can act after one read.

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 7-parameter tool with no output schema, the description covers purpose, sources, and the returned preview-plus-ref contract, which is the minimum an agent needs to chain into a story-creation tool. It is slightly incomplete on what happens with no matches and on the relationship between `query` and `dataset`, but overall it is adequate for 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 description coverage is 86%, so nearly every parameter already carries its own explanation, including the query phrasing hint and the top/pick/region semantics. The description adds no parameter-level meaning beyond that (nothing about how `dataset` interacts with `query`, or how `pick` narrows results). 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?

The description names a concrete resource and action: retrieving real statistics from named open-data catalogues (World Bank, SCB, Eurostat, Our World in Data) plus the channel's own statistics. It also states the deliverable (a preview and a `ref` for the story), which separates it from authoring siblings like create_data_story or create_visual_story. It falls short of a 5 because it never states the operation as a verb directed at a dataset, so the exact retrieval semantics ('fetch') are inferred rather than declared.

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 phrase 'never from memory' is a real usage directive: it tells the agent to call this rather than recall statistics. However, no sibling is named as the alternative, and there is no explicit when-not guidance (for example, whether to call this before or after create_data_story, or when an existing `dataset` id makes a re-search unnecessary). Usage is therefore implied rather than spelled out.

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