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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint=false, so safety is covered; the description adds substantial non-schema behavior: the exact sort tiebreak (company size within a date), why limit=15 during earnings week behaves as it does, the polling look-back/dedupe caveat for late-extracted filings, and the stated return field set. That is well beyond what annotations provide.

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 the triggering scenario, then Returns / Portfolio filter / related-tool routing, so an agent can stop reading early. It is dense but nearly every sentence carries routing or behavior information; the bold headers add structure at the cost of some length.

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 naming the returned fields and ordering, defining form_subtype values, and covering the mutation-adjacent pitfalls (late extraction, dedupe). Nothing an agent needs to call this correctly appears to be missing.

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 the baseline is 3; the description nevertheless adds meaning the schema only partially carries — the ticker/tickers union-with-cap-50 semantics, the alias equivalence, and the funnel from the 'since' floor plus the look-back dedupe advice. It stops short of documenting limit behavior beyond what the schema already says.

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 ('list recent SEC filings') and anchors it with concrete user phrasings ('any new 10-Ks this week?', 'who reported earnings today?'), which removes ambiguity about scope. It explicitly distinguishes itself from list_filings (one company, all history) and get_filing_section (read a row's content).

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?

Gives explicit when-to-use triggers via sample utterances, names the alternatives for adjacent needs (list_filings for a single company, get_filing_section to drill into a filing), and states the portfolio-union semantics and 50-ticker cap so an agent knows one call covers the whole portfolio. Also flags the non-point-in-time constraint and the past-date alternative.

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