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

Annotations provide readOnlyHint=true, so safety is covered. The description adds important behavioral nuances: it covers only current UTC month, includes coverage metadata and unknown-value counts, and has tier-specific limits (10 names for congress, 10/20 for insiders based on key type). This goes beyond the schema and helps set expectations.

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 description is three sentences, front-loaded with the core purpose and scope, then adds caveats and tier details. Every sentence adds value without redundancy.

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?

Given the tool's moderate complexity (ranked output with metadata and limits) and no output schema, the description covers the essential behavioral aspects. It could optionally specify whether results are sorted descending or include a date range, but the core usage is clear.

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%: both 'kind' and 'month' have descriptions with enums and default behavior. The description does not add much beyond reinforcing the month validity and tier limits, so baseline 3 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 clearly states the tool aggregates and ranks ticker activity from published filings for the current UTC month, with a specific resource (filings) and a clear distinction from sibling tools like list_congress_trades or list_insider_trades which likely list raw trades. It also disambiguates scope (current month) and adds a caveat that it's not total market activity.

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 it for ranked, aggregated monthly activity rather than raw lists, and for a broad overview. However, it doesn't explicitly state when NOT to use it or name alternatives for detailed trade-level queries, relying on the sibling names as context.

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