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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds useful context such as Yahoo Finance as the source, no API key required, and holder_type options, but it does not disclose return shape, data latency, or limits. This is acceptable given the annotations, but not rich.

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 compact and front-loaded: purpose, use-case bullets, holder_type options, and source are covered in about five short lines. The bullets slightly restate the opening purpose, but there is no real fluff and the structure is easy to scan.

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, idempotent fetch with an output schema present, the core use cases and source are covered. However, it does not differentiate from overlapping ownership-related siblings like Get13FHoldings or GetFundProfile, and it relies on the schema for symbol and filter details; with 0% reported schema coverage, that reliance makes it only partially complete.

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?

Reported schema description coverage is 0%, so the description must compensate. It explicitly documents holder_type values ('institutional', 'mutualfund', 'insider', 'all') and the data source, but it never mentions the symbol parameter or the filtering/context parameters. This is partial compensation, not complete parameter guidance.

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 opens with a specific verb-resource pairing: 'Fetch ownership data for a stock' and then lists concrete categories: top institutional holders, mutual fund holders, and insider transactions. This clearly distinguishes it from unrelated siblings like GetAnalystRatings or GetPriceHistory, and the mention of insider buys/sells makes the tool's unique scope explicit.

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 'Use this tool when' bullets provide clear trigger conditions: institutional ownership questions, insider activity checks, and ownership concentration analysis. However, it does not name sibling alternatives or say when not to use this tool, so it falls short of the top score.

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