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

Annotations already declare the tool read-only, idempotent, and non-destructive, so the bar is lower. The description still adds valuable behavioral context: figures come from official and industry-association sources, each record is labelled with its statistical body, and data from different bodies must not be merged due to scope differences. It also clarifies that the tool does not return prices. This goes well beyond the annotations.

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 well-structured with labeled sections: Purpose, Guidelines, Limits, and Ex. It front-loads the scope and the price-tool alternative, then packs source caveats and examples into a compact format. Every sentence earns its place, and there is no filler.

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 read-only overview tool with an output schema, no required parameters, and strong annotations, the description is complete. It covers what the module includes, the source caveats, when to use it, what it does not return, and example queries. Nothing an agent needs to invoke and interpret it correctly is missing.

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 100% for both parameters, so the baseline is 3. The description adds meaning to the region parameter by explaining it focuses the arisings table. However, it lists region values as CN/EU/US without mentioning GLOBAL, despite GLOBAL being valid in the schema enum; this is a minor gap. Language is optional and self-explanatory, so no additional description is needed.

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 states a precise purpose: an overview of the rCB feedstock module covering waste tyre arisings, recovery volumes, the processing-path value ladder, and module categories. It explicitly separates itself from pricing tools by stating it does not return prices and naming get_elt_price_index as the price tool. The title 'Feedstock Price Overview' is slightly misleading, but the description resolves this immediately.

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 gives explicit when-to-use guidance: use this tool before quoting feedstock availability or recovery-rate figures, then use get_elt_price_index for prices. It also explains the effect of the region parameter on focusing the arisings table. This is strong, actionable guidance with an explicit alternative tool.

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