Institution Portfolio Summary

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

With readOnlyHint already declaring the safety profile, the description adds substantial behavioral context: it explains that values normally use report-date closing prices, may fall back to filer values, and can include zero for unavailable valuations. It also discloses that ambiguous partial names return candidates rather than silently selecting a filer, which is important invocation behavior.

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 purpose is front-loaded and most of the length earns its place by enumerating return categories in the absence of an output schema. However, the description is a dense run-on sentence with repeated 'then' clauses, making it harder to scan than it could be. Slight structural improvement would raise this score.

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?

For a read-only tool with no output schema, the description is comprehensive: it covers portfolio summary fields, concentration and turnover metrics, report-date context, profile data from regulatory records, style bands, pricing caveats, and CIK resolution behavior. An agent has enough information to call it correctly and understand what comes back.

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 reportDate defaulting and off-quarter snapping. The description reinforces CIK/name behavior and date-count context but adds little parameter syntax beyond the schema. Baseline 3 is appropriate when the schema carries parameter semantics.

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 states a specific verb and resource: get the portfolio summary header for an institutional 13F filer. It scopes the result with concrete contents and explicitly clarifies that the value is published tracked 13F value, not total firm AUM. It also distinguishes name resolution via SearchInstitutions from silent filer selection.

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 clear usage guidance for the institutionName parameter, directing ambiguous partials to candidate CIKs and exact CIKs to SearchInstitutions. However, it does not explicitly say when to use this summary tool versus siblings such as GetInstitutionPortfolio, GetInstitutionQuarterlyActivity, or CompareInstitutionPortfolios. Main tool-selection guidance is therefore implied rather than explicit.

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