resolve_factor

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

With no annotations, the description carries the full burden and does so thoroughly: it explains that geography is parsed from the description, that omitting country yields a 'geo_match':'proxy' result, that 'review' is intentionally over-inclusive, and that absence responses have structural meanings that should stop the agent from retrying. This is far beyond minimal behavioral disclosure.

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 long but each paragraph earns its place: scoping, label semantics, and absence handling are all needed for correct invocation. The use of short capitalized hooks ('PUT THE COUNTRY IN THE DESCRIPTION', 'ACT ON THE LABEL', 'A MISS MAY EXPLAIN ITSELF') front-loads key behaviors and makes the density navigable.

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 three parameters, no annotations, and no output schema, the description provides everything needed to use the tool correctly: what it returns, how the main parameter behaves, how to interpret result labels, what absence responses mean, and how to hand off to related tools. No critical guidance appears 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%, so baseline is 3, but the description adds real meaning beyond the schema for the critical 'description' parameter: it emphasizes the country must be embedded in the text and gives concrete examples ('diesel per litre France'). This extra semantic context justifies a 4 above baseline.

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 specific operation ('find the best emission-factor key(s)') and a concrete resource ('for a plain-language description'), and explains the tool's distinctive role against the 16,000-key problem. It also positions the output as ranked matches with key/value/unit/confidence, and routes the chosen key onward to calculate_* tools or lookup_factor, which separates it from siblings.

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 usage direction: 'Prefer this over guessing a key', tells the agent to feed the chosen key to calculate_* or lookup_factor, and points to explain_absence for querying absence directly. It also provides actionable when-to-use/when-not-to-use guidance through the 'accept'/'review' labels and the absence classifications.

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