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 value by noting the tool returns source IDs and names and supports pagination, which are behavioral details beyond the annotations. No contradiction exists, and the added context is helpful for the agent to know what to expect.

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 sentences with no fluff. The primary purpose is front-loaded ('Lists the 70+ World Bank data sources'), followed by the return content and the pagination note. Every phrase earns its place, making it highly scannable for an agent.

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 tool's simplicity, existing output schema (indicated by context), and comprehensive annotations covering safety, the description covers all necessary context. It states the resource, the output fields, the downstream usage, and pagination. No critical information is missing for an agent to correctly select and invoke this 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%: both 'page' and 'per_page' have descriptive comments (pagination number and results per page, with defaults and max). The description only repeats 'supports pagination' which adds no meaning beyond the schema. Per the baseline, when the schema is sufficiently descriptive, the description does not need to add parameter details.

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 identifies the exact resource (World Bank data sources) and the verb 'lists', names specific examples (WDI, IDS, Doing Business), and states the output is source IDs and names. Critically, it differentiates its purpose by explicitly targeting use as source_id in worldbank_search_indicators, distinguishing it from sibling list tools like worldbank_list_countries and worldbank_list_topics.

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 clearly states when to use the tool: 'for use as source_id in worldbank_search_indicators', which tells the agent this is a preparatory step before searching indicators. However, it does not explicitly mention when not to use it or contrast with alternatives, so it lacks a full exclusionary statement. The intended usage is clear but not exhaustively defined.

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