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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, and the description adds substantial context beyond them: per-call pricing with a 10-free-call/day threshold, three distinct payment routes including escrow and seat-based access, and an explicit failure mode (indeterminate lines returned with first_call_help). No behavior contradicts the read-only annotation, since this is a computation that emits a notary payload and dry-run weave rather than mutating persisted state.

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 purpose is front-loaded and the example is well placed at the end, but the payment sentence packs three separate funding mechanisms (x402/Base USDC, escrow checkout, seats) into one dense clause, and the return-value enumeration duplicates what the output schema already declares.

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 single required-array tool with nested free-form activity objects, the definition covers purpose, cost, payment paths, error handling, and a worked example, and an output schema exists so return values need no further explanation. The main remaining gap is the unconstrained 'options' object, whose accepted keys are documented nowhere.

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?

With schema description coverage at 0%, the description must compensate, and the example arguments do heavy lifting by showing the activity object shape (id, activity_type, quantity, unit, region, year) and a valid activity_type vocabulary. The 'options' object, request_id, and the mechanics of payment_ref are still left unexplained, so compensation is partial rather than complete.

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: 'Calculate an auditable GHG inventory from explicit activity records', then enumerates the outputs (per-line gas/CO2e, Scope 1/2/3 rollups, dual Scope 2, factor lineage). It signals this is computation rather than classification or verification, but never names a sibling tool to route away from, so differentiation is only implicit.

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?

Usage context is implied by 'from explicit activity records' and 'This is calculation, not advice', and the payment section explains how to pay per call. However, there is no explicit when-to-use/when-not-to-use guidance relative to classify_activity or verify_result, so an agent must infer the boundary between classification, calculation, and verification.

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