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

Annotations already establish the safe read-only, closed-world profile, so the description's added value is the indexing semantics: 'products' and 'completedParts/totalParts' distinguish indexed, partial and waiting sources, and missing data is explicitly not evidence of absence. That is real interpretive context an agent would otherwise lack; only rate limits or auth expectations are absent.

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?

Four dense sentences with the core purpose front-loaded and no filler. The caveat about missing data and the pagination rule are both load-bearing, though the 'Products and completedParts/totalParts' phrasing is terse enough to be opaque on first 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?

With an output schema present, the description needn't explain return values, and annotations cover safety, so what remains is scope, filtering, caveats and paging — all covered. The main gap is sibling differentiation from search_world_find, which an agent choosing between the two would want.

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 coverage is a middling 60% — query, family and dimension are documented, while limit and offset are not. The description partially compensates by stating 'Up to 100 sources per page' (capping limit) and describing offset continuation, but it names 'nextOffset' rather than the actual 'offset' parameter, which risks confusing the agent about which field to pass.

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 uses a specific verb and resource — listing public Find sources plus their indexing coverage across NoCom, location WDLs and primary maps — which lets an agent distinguish it from sibling read tools like get_world_find_map or get_world_find_inventory. It does not, however, explicitly contrast itself with search_world_find, which is the nearest name-alike.

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?

It gives operational guidance on filtering (by dimension, family, or name/ID) and on pagination ('Follow nextOffset with unchanged filters'), plus a useful caveat that missing data does not establish absence. What it never states is when to choose this over search_world_find or the other world-find lookups, so usage is implied rather than directed.

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