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

Annotations already establish read-only, idempotent and non-destructive, yet the description still adds substantial non-obvious behavior: the default fiscal year, the subtotal/foreign-table response when state is omitted, that masked recipients stay masked, that unmatched rows are still payments, and that foreign sharing is never merged with domestic totals. These are exactly the traits that prevent misinterpretation of results.

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 core action, default and filters are front-loaded in the first two sentences, and the length is justified by dense, non-redundant content. The closing sentences on ESAC fiscal years and the seizure/conviction distinction are interpretive guidance rather than tool mechanics, but they still prevent real analytical errors.

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, and the description fills that gap explicitly by enumerating returned fields (DOJ cash, sale proceeds, total, original recipient name, match method, ORI). Combined with the fiscal-year default and masking rules, an agent has enough to call it and interpret the result 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 coverage is 100%, so the schema already documents all five parameters and a baseline of 3 applies. The description goes beyond it by explaining the consequence of omitting state (subtotals plus a separate foreign-sharing table) and by clarifying that recipient matching is substring-based and never unmasks a masked name.

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 gives a specific verb (Search) plus a precisely narrow resource (DOJ equitable-sharing payments to state, local and tribal agencies) scoped by federal fiscal year. That level of specificity lets an agent separate it from siblings like forfeiture_agency or judgment_fund_payments without opening any schema.

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?

It states defaults and conditional behavior ("with no state filter, returns all state subtotals and a separate foreign-sharing table") and warns against combining ESAC certifications with these payments, which is useful guardrail guidance. However, it never names an alternative tool or says when to pick forfeiture_agency or judgment_fund_payments instead, so routing is left to inference.

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