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

Beyond the annotations (readOnly/openWorld=false/destructive=false), the description discloses meaningful semantics: the value is published tracked 13F value, explicitly NOT total firm AUM; values use report-date closing prices, may fall back to filer values, and can be zero when unvalued. It also states that ambiguous partial names return candidates rather than silently select a filer. These are non-obvious behavioral caveats that the annotations do not cover.

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 core content is front-loaded (the summary fields come first), but the entire description is one very long run-on sentence chained with 'then ... then ... then', which is hard to parse. Given there is no output schema and return contents must be conveyed, the length is defensible, but the packing is denser than it needs to be.

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 carries the burden of describing return values and does so comprehensively: the summary metrics, the holder profile layers (regulatory record, Form ADV, parent filer, prior/next CIKs, filed brochure strategy, style bands), plus data-quality caveats and the CIK-resolution flow. An agent has enough to call this correctly.

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 schema already documents both parameters, including the off-quarter snapping and partial-name resolution behavior. The description reinforces but does not extend those semantics, so the baseline 3 is appropriate; the schema does the heavy lifting here.

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 gives a precise verb+resource ('portfolio summary header for an institutional 13F filer') and enumerates exactly what it returns: tracked 13F value, position count, top-10/25 concentration, QoQ turnover, report dates, holder profile, Form ADV facts, style/horizon bands. This is highly specific, but it never names or contrasts against closely related siblings such as GetInstitutionPortfolio, GetInstitutionQuarterlyActivity or GetHolderMix, so the agent must infer the boundary itself.

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 routing guidance for input resolution: 'Resolve exact CIKs with SearchInstitutions; ambiguous partial names return candidates rather than selecting a filer silently.' This names an alternative tool and the condition for using it. However, there is no when-to-use/when-not guidance relative to the portfolio- and ownership-summary siblings, so the usage context is clear but incomplete.

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