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

Annotations already convey read-only, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds value by explaining the meaning of the filings (13D vs 13G) and the exact fields returned (issuer, CUSIP, reporting person(s), percent of class). This contextual disclosure goes beyond annotations and helps the agent understand the tool's output semantics without an output schema.

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 four sentences long but each sentence earns its place: it defines 13D/13G, clarifies the threshold, lists the record fields, and explains the identifier modes. It is front-loaded with purpose and avoids filler, though the first two sentences could arguably be condensed. Overall it is efficient and well-structured for an agent scanning for key information.

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 no output schema, the description provides a useful outline of return fields (issuer, CUSIP, reporting person(s), percent). It also covers the two invocation modes thoroughly. It does not mention pagination, error behavior, or edge cases, but for a read-only, idempotent tool with a single required parameter, these are less critical. The description is sufficient for correct invocation and basic outcome expectations.

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?

All four parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds meaningful depth to the required 'identifier' parameter by explaining the two distinct value modes ('latest' vs ticker) and their purposes, which the schema merely hints at. This elevates the semantic clarity of the most important parameter beyond what the schema alone provides.

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 specific resource (13D/13G activist stakes) and a clear action (get/fetch), going beyond the name to explain the domain context (5% threshold, 13D vs 13G). It also distinguishes two modes of operation (latest vs ticker) that align with the identifier parameter, making the purpose unambiguous and distinguishable from sibling tools like get_holdings or get_filings.

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 explicitly tells the agent when to use each identifier value: 'Pass identifier='latest' for the market-wide feed... or a ticker for the stakes indexed on that company.' This is clear usage guidance for the primary parameter. It does not explicitly compare against alternatives (e.g., get_holdings), but the distinction between activist stakes and general holdings is implicit. The guidance is specific enough to correctly invoke the tool for both intended scenarios.

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