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

With no annotations, the description carries the full burden and does substantial work: it discloses the 25-calls/day per-IP free allowance, the X-Free-Call: 1 or ?free=1 mechanism, the $0.005 USDC x402 charge, and that the data is public domain with no legal advice. It stops short of describing pagination across the total_matches/returned split or error/failure behavior when the allowance is exhausted, which keeps it below a 5.

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?

Commercial boilerplate about free tier and pricing is front-loaded ahead of the actual purpose, so an agent skimming the first clause learns the billing model before the function. The example output is also truncated mid-field ("url":" ), which wastes space without delivering a usable sample, though the remainder is dense and largely free of filler.

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 9-parameter, all-optional search tool with no output schema, the description supplies an inline example response showing the returned document shape, covers the document-type taxonomy that maps to the type enum, and explains the payment model. The gaps are the unmentioned sort parameter and the absence of any note on how limit interacts with total_matches.

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 89%, so the schema already explains q, to/from, free, type, limit, agency, and comments_open. The description adds only a grouped restatement of the filter axes plus the ?free=1 alternative, and it says nothing about the undocumented sort parameter or the limit ceiling beyond what the schema states. Baseline 3 applies when the schema does the heavy lifting.

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 names a specific verb and resource — search the US Federal Register — and enumerates the document classes covered (final rules, proposed rules, notices, presidential documents) along with the fields returned. That is enough to distinguish it from sibling tools such as sec_filings, papers_search, and clinical_trials_search 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 the filter axes (keyword, type, agency slug, date range) and the free-tier/payment context, which implies when to reach for it, but it never says when not to use it or names a sibling alternative for overlapping needs like SEC or academic search. Usage is implied rather than explicitly routed.

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