Latest SEC filings (10-K / 10-Q / 8-K)

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds valuable behavioral context beyond annotations: the 40-item cap, the 10-minute refresh cadence, the UTC timestamp format, and the per-call cost/settlement mechanism. It does not describe pagination or what happens when more than 40 filings exist, but the cap is explicitly stated.

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?

Three sentences with no wasted words. The core purpose is front-loaded, followed by the item shape and the cost/settlement detail. Every sentence earns its place, and the structure is easy to scan.

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 zero-parameter read-only tool, the description is nearly complete: it covers scope, ordering, limits, refresh behavior, item fields, and cost. There is no output schema, so the description's item list partially compensates, but it doesn't specify the exact JSON shape or field names. The absence of pagination details is a minor gap given the explicit 40-item cap.

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?

The tool has zero parameters, so the schema is trivially complete (100% coverage). The description adds meaning by explaining what the returned items contain (form type, company name + CIK, filing time, EDGAR URL) and the ordering, which is useful context even though there are no parameters to document. Baseline 4 for zero-param tools is appropriate.

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 verb ('Latest SEC EDGAR filings'), a precise resource (10-K / 10-Q / 8-K form types), and a clear scope (sorted by filing time descending, max 40 per call). It distinguishes itself from siblings by naming the form types and the aggregation across them, so an agent can tell it apart from sec_filings_8k 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?

The description implies when to use this tool: when you need a broad, recent cross-form-type view of SEC filings. It does not explicitly name the sibling alternative sec_filings_8k or state when to choose that instead, but the form-type scope and the 'max 40 per call' constraint give clear context. A brief exclusion ('for 8-K only, use sec_filings_8k') would make it a 5.

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