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

Annotations already mark the tool read-only and non-destructive, but the description goes far beyond that with valuable behavioral details: it discloses the data source, excludes consolidated tape volume, flags a pre-2025-08-11 data quality issue involving case-variant sibling securities, and explains FINRA's publication delay. No contradictions with annotations exist.

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?

Every sentence adds value: the first front-loads the core purpose, then the description details output composition, explains a data limitation, highlights a historical data quality caveat, and clarifies the lag. Despite its length, no filler or redundant text exists.

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 data retrieval tool with no output schema, the description covers the essential context: data source, what each record includes, important caveats, and timing. Parameter details are fully handled by the schema. It does not mention edge cases like missing data or invalid tickers, but that is not critical for this tool's usage.

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?

The input schema has 100% description coverage for all four parameters, so the description does not need to repeat parameter details. It adds interpretive meaning about the returned breakdown (ATS + non-ATS OTC) but does not elaborate on parameter formatting beyond what the schema already provides. This matches the baseline for well-covered schemas.

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 exactly what the tool does: 'Get weekly off-exchange (dark pool / OTC) trading volume for a stock' from FINRA OTC/ATS data. It names concrete output components (ATS volume/trade count, non-ATS OTC volume/trade count, total off-exchange volume), distinguishing it from sibling tools that cover other volume data like short volume or on-balance volume.

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 context for when this tool is appropriate: to retrieve off-exchange volume data and to understand its weekly publication lag. It explicitly advises not to derive market share from this data because consolidated tape volume is absent, directing the agent to compute that elsewhere. It does not name specific alternative sibling tools, so there is no explicit 'use X instead' statement, but the guidance is clear enough.

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