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

Annotations already cover read-only, idempotent, non-destructive, closed-world, so the bar is met; the description still adds substantial behavior: newest-first ordering, data since 2009, the 30-day market cap with a note when the range is narrowed, a 200-row-per-call limit with pagination, and that filing text is not stored. These are operational constraints an agent needs and none duplicate the annotations.

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?

The material is front-loaded with the resource, but it is delivered as one dense run-on paragraph mixing scope, form taxonomy, output fields, retrieval guidance, and pagination. The mid-sentence catalog of 8-K item codes with descriptions is heavy for a description, and a few structural breaks would make it far easier to parse.

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?

Despite an output schema existing, the description explains the row shape (accession, form, item codes, filed_date, accepted_at, period_of_report, ticker, url/sec_url/index_url) and how to retrieve underlying text, leaving no ambiguity for an 8-parameter, zero-required tool. Combined with the annotations, nothing needed to invoke it correctly is 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 3 is the baseline; the description goes further by explaining that items matches 8-K filings containing any of the given codes (and only 8-K/8-K-A have items), that forms includes amendments, and that ticker/cik should not both be given. It adds meaningful semantics over the schema, though much of the row-field detail belongs to the output shape rather than inputs.

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 resource (SEC filings: 10-K, 10-Q, 8-K, 20-F, 40-F with amendments) and both scopes (a single company or the whole market). It is immediately distinguishable from siblings like get_ownership_filings, get_financials, or get_major_holders, which cover different datasets. An agent does not need to open the schema to know what this returns.

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 gives clear conditional guidance: with ticker/cik the full company history is searchable (including former CIKs), without either the query covers the market but is capped at 30 days (default 7). It also directs the agent to sec_url / index_url for the actual filing text since Livermore stores none. It does not, however, name any sibling tool as an alternative when the agent wants ownership or financials instead, so routing between siblings is left implicit.

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