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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the core safety profile is covered. The description goes beyond this by detailing the response structure (one-paragraph interpretation block vs pure JSON), naming specific metrics included, and disclosing abuse controls (rate limits, Pro-only enforcement, and backend key requirements). It also notes that some metrics appear 'when rows exist,' which adds valuable behavioral nuance.

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 long, spanning several paragraphs with detailed behavioral and configuration info. While each sentence adds value (interpretation format, auth, rate limits), it is not concise. The purpose is front-loaded, but the abuse-control and internal-key details could be condensed or moved to annotations. It reads as thorough but not lean.

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?

The description covers response structure, authentication (a2a_internal_api_key), rate limiting, and optional Pro gating, which is rich context for a complex tool. Given there is an output schema, the description doesn't need to explain every return field. Missing limit_per_table semantics is a gap, but overall it is sufficiently complete for an agent to call 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?

With 0% schema description coverage, the description must compensate. It thoroughly explains include_interpretation (the interpretation block vs JSON only) and implicitly defines symbol as 'one ticker.' However, limit_per_table is never mentioned. Since one of three parameters is left unexplained, it only partially compensates for the missing schema descriptions.

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 'Return MoneyChoice aggregate stock analysis for one ticker,' which is a clear and specific verb+resource+scope statement. It distinguishes this tool from the sibling forecast_* tools by explicitly using 'analysis' vs 'forecast,' making its unique purpose obvious without needing to name alternatives.

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?

There is no explicit guidance on when to use this tool versus alternatives. The description provides usage instructions for the include_interpretation parameter (set false for JSON only), but does not mention any sibling tools or conditions that would lead an agent to choose this over forecast_equities. The context implies it's for stock analysis, but it lacks explicit exclusions or alternatives.

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