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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds only a UI-scope note and discloses nothing else behavioral — not that this is a pure cost computation with no side effects, whether it consumes credits, or any auth/rate constraint.

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?

It is very short and the scope constraint is front-loaded, so there is no wasted text. The problem is under-specification rather than verbosity — the second sentence is a fragment with no verb, which reads as truncated output rather than a deliberate concise statement.

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 an 18-parameter, four-modality pricing tool the description is far too thin: it never says it produces a cost estimate, never mentions that the required model id must come from list_models, and never explains how it relates to app_generate or estimate_run. An output schema exists so return values need no explanation, but the input-side and selection context are missing.

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 description coverage is 100% and the schema itself is unusually rich, explaining per-kind applicability for all 18 parameters. The description adds no parameter-level meaning whatsoever, so the baseline 3 applies.

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 contains no verb stating what the tool does ("quote"/"estimate a price"); the purpose is only recoverable from the title "Price the composer (app)". It does supply a genuine scope boundary ("the Veltake app's own screens only — not for a conversation"), which distinguishes it from the conversation-oriented siblings, but the core action is left implicit.

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 names a sibling, estimate_generation, and draws a context line between app screens and conversations, which is real routing information. However, the phrasing "estimate_generation for the composer's settings" has no verb and is ambiguous about whether it is a recommendation, a contrast, or an unrelated note, so the agent cannot be certain which tool to pick.

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