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

Annotations already carry readOnlyHint=true and destructiveHint=false, and the description adds genuinely valuable behavioral context beyond them: the Δ1Treatment (entries = full position, exits = −prior position), the requirement that 13F filings exist in both quarters, and the CIK-migration caveat preventing false full-position changes. It also discloses the partial-coverage behavior during the current filing window and the markdown-table output shape.

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?

Five sentences, each earning its place: the headline outcome, the delta semantics qualifying what 'buyer/seller' means, the filing-qualification caveat, the open-window caveat, and the return format. It is longer than minimal, but every clause carries a distinct, load-bearing fact for a conceptually tricky tool.

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 complexity (delta semantics, dual-section output, filing caveats) and the absence of an output schema, the description compensates well by describing the markdown-table result and two-section structure. Minor remaining gaps are output-level details (exact columns, tie-break ordering), which no schema exists for, so the description carries a reasonable share but is not fully airtight.

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%, with rich per-parameter descriptions (ticker example, maxResults default and clamp, reportDate format/default, and snapping behavior), so the baseline is 3. The description adds some context by defining 'previous 13F report date' and delta semantics, but it does not materially extend the parameter-level meaning for ticker, maxResults, or reportDate beyond the schema.

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 precise verb and resource ('Get the institutions... biggest absolute share additions ... and reductions versus the previous 13F report date') and adds the unambiguous distinguishing detail of including new positions and sold-out positions. This differentiates it from siblings like GetTopHolders, GetInstitutionalOwnershipHistory, and GetMarketWide13FActivity without needing to open 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 gives explicit context: surface the most actionable quarterly signal from 13F filings, and it qualifies applicability (only funds that have filed when the window is open). It does not, however, name sibling alternatives for other use cases (e.g., GetInstitutionQuarterlyActivity or GetInstitutionalOwnershipHistory), so it lacks the when-not-to-use guidance needed for a 5.

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