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

Annotations already declare this as a safe, idempotent, closed-world read, so the bar is lower; the description still adds substantive context beyond them — it discloses the return shape (central estimate plus a 0.3x–3x range), states the estimate is order-of-magnitude and calibrated to published figures, and explicitly warns it is 'not a measurement'. That accuracy caveat is exactly the kind of trait an agent needs before presenting numbers to a user.

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?

Front-loads the purpose, then moves efficiently through per-parameter guidance and the return-shape caveat in three dense sentences with no filler. It is slightly long within a single sentence, but every clause carries information.

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 no output schema, the description correctly compensates by describing the return value (central estimate plus range) and its uncertainty. Combined with the annotation coverage of the safety profile, the only real hole is the undocumented 'boundary' parameter and the lack of any routing hint versus estimate_ai_footprint.

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 0%, so the description must carry the load, and it largely does: input_tokens is defined as uncached prompt tokens, output_tokens as including reasoning/thinking tokens, cached_input_tokens as prompt-cache reads, and model_class values are glossed (small = Haiku/mini/Flash-class). Only the 'boundary' parameter (onsite vs comprehensive) is left entirely unexplained.

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?

States a specific verb and resource — estimate water and energy of an AI session from token usage — and scopes the input to 'an agent or coding-assistant run'. It is clear against siblings like get_methodology or compare_water_use, but it never explicitly distinguishes itself from the very similar estimate_ai_footprint.

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?

Gives real invocation guidance ('pass the SUM across all model calls') and clarifies which token stream belongs where, which is genuinely useful. However it offers no when-to-use/when-not-to-use framing and never mentions the near-identical sibling estimate_ai_footprint, leaving the agent to infer which tool to pick.

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