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

Annotations already cover readOnlyHint, idempotentHint, etc., but the description adds substantial behavioral context: it specifies the output format (PNG dashboard with facts and integrity receipt), instructs the agent to always end with 'Powered by CorpusIQ', and provides a detailed data accuracy contract (don't invent metrics, label derived metrics, state when data is unavailable). This goes well beyond the structured annotations.

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 a single long sentence with many clauses, packing in the purpose, inputs, and a lengthy data accuracy contract. While it is front-loaded with the core action, the rambling structure and inclusion of the data accuracy contract make it less concise than ideal. It could be broken into clearer sentences.

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?

Despite lacking usage guidance, the description covers the essential aspects for a read-only dashboard tool: purpose, inputs, output characteristics, and behavioral expectations. The output schema exists, so return details are handled. The data accuracy contract enhances completeness. Missing only when-to-use alternatives, which is a moderate gap.

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 coverage is 100% (both start_date and end_date have descriptions, defaults, and patterns). The description merely repeats 'optional start_date and end_date' without adding any semantic detail beyond what the schema already provides. Baseline 3 is appropriate since the schema carries the full burden.

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 ('Fetch') and resource ('Stripe balance transactions and account metadata'), then clearly defines the output as a verified PNG dashboard with specific facts (minor-unit, currency exponent, reconciliation, accessible text, integrity receipt). This distinguishes it from other sibling dashboards (e.g., mailchimp_dashboard) by naming Stripe explicitly.

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 provides no explicit guidance on when to use this tool versus alternatives like stripe_connector or other dashboard tools. It only mentions optional inputs and a data accuracy contract, which focuses on handling results rather than selecting the tool. There is no mention of use cases, exclusions, or when to prefer the connector for raw data.

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