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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing ordering (newest first), a result ceiling (~1000), form-type exclusions, the exact return fields, and the paid-call mechanics (x402 USDC on Base, $0.002 per successful call, PaymentRequired object returned when unpaid). The pricing and payment-handshake behavior is critical context no annotation conveys.

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-loads the 'Use when' trigger, then packs output shape, exclusions, and payment terms into compact clauses with no filler. Dense but each clause carries information an agent needs; only the long enumeration of return fields slightly strains readability.

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 compensates by enumerating the returned fields (filing date, period of report, accession number, 8-K item codes, size, primary-document and index URLs). Combined with the filtering, exclusion, and payment details, an agent has everything needed to call and interpret this tool.

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 every parameter (cik, ticker, forms, limit, since) is already documented, and the description's form-type and date filtering largely restates that. Baseline 3 applies since the description adds the default form set context but no new syntax or format guidance.

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 verb and resource ('lists the company's recent EDGAR filings') plus the exact scope (newest first, up to ~1000, filtered by form type and date). It is clearly distinguishable from siblings company, financials, and search because it is explicitly about the filings list rather than a profile or financial statements.

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?

'Use when you need to find a company's annual report, latest quarterly report, recent 8-K events or registration statements' gives concrete triggering scenarios, and the insider/beneficial-owner exclusion (3/4/5/144/13D/13G) tells the agent when this tool will not return what it wants. It stops short of naming which sibling to use instead for those excluded forms.

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