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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is fully consistent with these. Beyond that, it discloses substantial extra behavior: the exact-vs-range return pattern, the explicit accuracy caveat ('does not promise an accuracy percentage - check cost_range'), the ~100ms latency, the free/no-key requirement, and the 60-second caching recommendation. This is rich behavioral context the annotations do not carry.

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 longer than average but tightly structured with labeled sections: core behavior, examples, WHEN TO USE, WHEN NOT TO USE, COST, LATENCY. Core behavior is front-loaded in the first sentence, and every section carries functional information. The two examples are slightly redundant with each other but still earn their place by demonstrating parameter usage.

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 carries the burden of conveying return values, and it does: cost, latency, and success-probability estimates, plus the cost_range field and exact-vs-range distinction. Operational traits (free, latency, caching) are included. Minor gap: no edge-case behavior described, such as handling of unknown operation names, but for a two-parameter preview tool the essentials are all present.

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 50% (the 'params' field is described but 'operation' is not), so the description must compensate. The two worked examples do exactly that, showing the JSON structure with concrete values like preview_cost({"operation": "send_message", "params": {"preferred_channel": "sms"}}). This clarifies that 'params' mirrors the operation's request body and demonstrates realistic values, adding meaning well beyond the bare schema.

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 and resource: 'Return an expected cost estimate, latency estimate, and success-probability estimate for a proposed call before execution.' It clearly explains the exact-price vs min/max-range behavior. The 'before execution' qualifier cleanly separates it from the sibling tools, which all concern compliance, status, and verification rather than cost.

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?

Explicit WHEN TO USE guidance is given: before any operation when operating under a budget constraint and needing to decide whether to proceed. WHEN NOT TO USE excludes hot loops and mandates 60-second caching. No specific alternative sibling is named, but none of the siblings (check_compliance, get_outcome, screen_sanctions, etc.) is a cost-estimation tool, so no routing alternative exists to cite.

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