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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds content-level context — that results include sealed v7.4/v7.5 contributions, outcome availability, automatic Quality and optional reviewed bonus — which is genuine behavioral value beyond the annotations, though the terms are unexplained.

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?

It is a single front-loaded sentence, which is good structure, but it is dense with undefined jargon ('sealed v7.4 or v7.5 contributions') that spends words without informing the agent. Efficient in length, weak in information density.

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?

No output schema exists, so the description must explain what an 'explanation' returns and what the handle refers to; it does neither adequately. For a tool with 0% parameter documentation and no return schema, the description leaves essential invocation details 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 description coverage is 0% for 2 parameters, so the description carries the full burden. It only obliquely implies 'handle' refers to a receipt and 'dimension' is one impact dimension; neither the handle format/source nor the meaning of the enum values is clarified. The enum itself documents the allowed dimension names, but nothing explains them.

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+resource: 'Explain one impact dimension from the selected policy receipt'. An agent can tell it produces a per-dimension explanation, distinct from get_impact_profile or explain_verification. However, the trailing clause ('sealed v7.4 or v7.5 contributions', 'outcome availability') is opaque domain jargon that doesn't sharpen the purpose.

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?

There is no explicit when-to-use guidance, no when-not-to-use, and no mention of the closely related sibling explain_verification. The phrase 'selected policy receipt' weakly implies a prior selection step but never states the precondition or how to obtain a handle.

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