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

Annotations already cover readOnly and openWorld, yet the description adds real value beyond them: the exact billing model ($0.002 USDC per successful call via x402 on Base/Solana/Arc, failed calls not charged) and the explicit limitation that offering amounts are not parsed. This is the kind of cost and scope detail structured fields cannot express.

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?

Front-loaded with what the tool returns, then the scope caveat, then pricing — each sentence earns its place. The opening sentence is somewhat run-on but remains dense and scannable rather than padded.

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?

An output schema exists, so field-level return detail is rightly omitted. The missing piece is a bound on 'Latest' — no date-window parameter or statement of how far back the index goes — which an agent would want before relying on the result set.

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% and both parameters are fully documented in the schema, so the description carries no obligation to restate them. It adds nothing about how 'query' matches beyond what the schema says, which lands at the baseline 3.

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 resource (SEC Form D filings from EDGAR's public search index) and enumerates the exact returned fields (filer name, CIK, filing date, state, accession number). The parenthetical '(private securities offerings, Reg D)' disambiguates it from the sibling finance_sec_form4 and other SEC siblings without needing the 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?

The scope limit 'Lists filings only; the offering amounts are not parsed' is useful negative guidance, and 'Optional words to match' implies a search mode. However, there is no explicit statement of when to prefer this over siblings like finance_sec_form4 or finance_sec_iapd, and 'Latest' is never bounded (how recent?), leaving the agent to infer behavior.

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