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

With no annotations, the description carries the full burden and does so thoroughly: it explains the freeze[] status vocabulary, why 'unknown' must not be read as 'not frozen' (backfill incomplete), that frozen_usd6 is a locked face value read later than the act, that absent means 'not read' never zero, and that empty lists mean 'no act indexed' rather than clean. It adds provenance limits, a FREEZE_PROPOSALS_PUBLIC gating condition, and an explicit disclaimer that it is not an identity/AML/legal determination, plus 'No auth.'

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 first sentence is front-loaded with the core purpose, and the volume of field semantics is defensible given there is no output schema. But the rest is a single dense paragraph of nested parentheticals and semicolons with no list structure, making it hard to parse for the fields an agent most needs. It is information-rich but structurally poor.

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?

There is no output schema, so the description must describe return values, and it covers every field (freeze[], not_freezable[], frozen_elsewhere[], freeze_proposals[]) plus their edge-case semantics. Given the complexity and the absence of structured return documentation, this is complete enough for an agent to interpret results correctly.

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 100%, so the schema already documents both the chain spelling rules, defaults, and the address format. The prose adds no parameter-level meaning beyond what the schema states, so the baseline 3 applies. The heavy detail in the description is about return fields, not inputs.

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 first sentence names a specific verb and resource — per-address Class-F compliance facts on ONE chain, plus the OFAC SDN flag — so an agent can tell broadly what it returns. It also explicitly distinguishes itself from get_address_risk ("the cross-chain signal get_address_risk does not score"). However, it never differentiates from the closest sibling, get_sanctions_status, which also concerns OFAC/sanctions status, so sibling differentiation is only partial.

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 through embedded guidance: "read it before concluding, then ask again with chain set" and the note that this scores cross-chain signals get_address_risk does not. But there is no explicit statement of when to prefer this tool over get_address_risk or get_sanctions_status, and no exclusions. The routing advice exists but is scattered rather than stated as an if/then.

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