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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: the unit engine converts to the factor basis (with example conversions: MWh→kWh, tonne→kg, gallon→litre, mile→km) and returns the emissions with the working, GHG Protocol scope, and source. This goes beyond the raw schema and gives concrete insight into the tool's output and conversion logic, though it does not mention failure modes or validation behavior.

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 three sentences, each earning its place: the first states the purpose and formula, the second gives the input instructions and output highlights, and the third points to companion lookup tools. It is front-loaded with the core purpose and has no redundant or filler content.

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 has no annotations and no output schema, the description covers the essential context: what it does, how inputs are transformed, what the response includes, and where to find factor keys. It is complete enough for an agent to select and invoke the tool correctly. The only gap is the lack of explicit mentions of error conditions or unsupported units, but the description still provides strong operational guidance.

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 the baseline is 3. The description adds meaning beyond the schema by explaining the unit conversion behavior ('the unit engine converts to the factor basis') and providing examples of supported unit mappings. It also advises how to find the factor_key via search_factors/lookup_factor, giving practical context for that parameter. This raises it to a 4, though it does not fully detail every edge case for the activity object's value.

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 opens with a clear statement: 'Turn activity data into greenhouse-gas emissions: emissions = activity × factor.' This names the specific verb ('turn'/'calculate'), the resource ('greenhouse-gas emissions'), and the exact formula. It distinguishes from the specialized siblings (calculate_electricity, calculate_freight, etc.) by positioning itself as the generic activity calculator, and it points to search_factors/lookup_factor for factor keys, reinforcing its role.

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 provides usage instructions: 'Give an amount + unit and a factor key' and advises using search_factors/lookup_factor to find the factor key. However, it does not explicitly state when to prefer this tool over the sibling calculate_* tools or when not to use it. The guidance is implied (generic vs. specialized) but lacks explicit exclusions or alternative selection criteria.

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