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

Despite annotations already declaring readOnlyHint, the description adds substantial behavioral context the annotations cannot: tiered access rules (first 5 rows plus a by-type count without a paid plan), what is never returned (contact values, decision-maker names), and the 'entitlement'/'locked' fields that disclose withholding. This is exactly the beyond-annotation disclosure the dimension asks for.

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 in the first clause, and the long field enumeration earns its place because there is no output schema. Sentences are dense and run long, and the entitlement/promotional tail ('7 days free at...') is the least essential part, but overall the content is proportionate.

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 carries the full burden of explaining return values, and it does so exhaustively—listing every metric per pattern and explaining the entitlement/locked withholding fields. For a 5-param, enum-rich read tool, an agent has everything needed to call and interpret it.

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 40% and two filter params (status, vertical) carry enum values. The description adds meaning by naming which fields are filterable ('vertical, status or signal key'), compensating partially for the undocumented limit parameter. It adds little beyond confirming the filters and gives no syntax for cursor or limit.

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 description states a specific resource and scope: 'The ledger behind every forward claim,' followed by an enumeration of exactly what each record contains (definition, base rate, lift, lead time, q value, status). This distinguishes it from the opportunity-finding siblings and from search_signals. It stops short of naming a sibling to contrast against, so it is clear but not fully differentiated.

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?

The only operational guidance is 'Filter by vertical, status or signal key,' which describes parameters rather than when to choose this tool over search_forward_opportunities or search_signals. The note that rejected patterns are intentionally listed hints at a methodology-audit purpose but does not state when to reach for this versus the alternatives. No when-not or exclusion guidance is given.

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