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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: it is static reference text with no network lookup, which tells the agent results never go stale and need not be re-fetched. It also scopes the content ('what each one can and cannot show'), setting expectations about interpretation limits.

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?

A single front-loaded sentence with the key claim ('plain-language definitions') first, followed by the signal list and the static/no-lookup qualifier. The enumeration is long but each item is load-bearing for an agent deciding whether the answer it needs is included; nothing is redundant.

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 parameterless static reference tool with no output schema, the definition tells the agent what it returns, that it is offline, and what interpretive limits accompany each signal. The only minor gap is that it does not say whether definitions are chain- or token-specific, though 'static reference text' largely resolves that.

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?

The tool takes zero parameters, so the baseline is 4; there is no parameter meaning for the description to supply. The enumeration of covered signals usefully signals that no filtering argument exists — all definitions are returned together.

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 ('Returns plain-language definitions of the signals found in a token safety report') and then enumerates the exact signals covered, so an agent knows precisely what content comes back. The closing clause 'Static reference text' further pins down the nature of the response, distinguishing it from the sibling check_token_safety that performs the actual analysis.

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 is implied by the phrase 'signals found in a token safety report' — an agent can infer this is the follow-up to reading such a report — but the description never says when to call this instead of check_token_safety or get_token_holders. No explicit trigger, prerequisite, or exclusion is given.

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