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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so safety is covered; the description adds real behavioral context beyond that: each source and currency is kept explicit, attribution is not inferred without an identity join, cadence counts appear only when customer-level subscription data exists, and RevenueCat ARR is derived as normalized MRR x 12. These are meaningful disclosure about result semantics and limitations. It does not discuss limits, pagination, or partial-source failure behavior.

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 metric inventory is front-loaded and each later sentence (cadence counts, ARR derivation, no-inference rule) adds distinct information. The trailing MCP invocation note and free-credit sentence are boilerplate that does not help tool selection and dilutes the body slightly.

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?

With no output schema, the description must characterize the payload, and it does: named metric families, cadence breakdowns, and the guarantee that sources and currencies stay separate. For a read-only aggregation over three systems this is largely sufficient, though result shape (structure per source/currency) and behavior when one source is unconnected are left implicit.

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 75%, so the schema largely documents from/to, accountIds, userStatement and idempotencyKey itself. The description adds nothing about the date-window semantics, account scoping, or how idempotencyKey relates to what is described as a read-only tool. Baseline 3 applies when the schema carries the parameter 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 names the exact data sources (Stripe, RevenueCat, PostHog) and enumerates the metrics returned: active subscriptions, trials, normalized MRR, ARR, collected payments, refunds, daily product events, plus customer/subscription counts by billing cadence. That is far more specific than the title 'Saas performance'. It does not, however, explicitly contrast itself with adjacent siblings such as store_revenue, metrics_daily or performance_period.

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?

It gives a concrete usage directive with an example question ('how many customers pay annually or monthly'), which tells an agent the intended question class. It offers no exclusions or named alternatives, so the agent must infer routing against the many sibling analytics tools.

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