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

Annotations already declare readOnlyHint=true, and the description adds substantive behavioral context: it's a 45-day-stale quarterly snapshot, long-only, and explains the limitation behavior with a concrete example (Renaissance with 3,213 positions, top 200 = 56% of value). This goes well beyond the annotation, providing realistic expectations about data freshness and completeness.

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 a series of sentences that each add distinct value: purpose, axis distinction, data characteristics, and limitation behavior. It is not overly verbose, but it is somewhat long. The front-loaded purpose and distinction make it easy to parse; a 4 reflects its efficiency without being exemplary.

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 an output schema present, the description needn't detail return values, and it covers data freshness, axis context, and the partial-portfolio warning. The only gap is the undocumented 'entity' parameter, which prevents full completeness. Overall it is comprehensive but not perfect.

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 schema has 0% description coverage, so the description must carry the burden. It does explain the manager parameter (fund name, ticker, or CIK) and implies the limit parameter's effect ('raise limit for more'), but the entity parameter is not mentioned at all. This partial coverage is sufficient for some parameters but leaves a key one undocumented, so a 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 it returns the latest disclosed 13F holdings for an institutional manager, with a specific definition (fund name, ticker, or CIK) and ordering (largest positions first). It explicitly differentiates the manager-axis from get_filings(kind='events') which is issuer-axis, so an agent can distinguish it from a sibling without confusion.

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 explicit guidance on when to use this tool vs. the sibling get_filings, and states the behavioral nuance about limited results: for partial portfolios, pct_of_portfolio won't sum to 1 and the note explains how much is shown, with a directive to raise limit for more. This is concrete, actionable guidance.

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