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

With no annotations present, this description carries the full behavioral burden, and it delivers: it discloses the consent-gated flows, the two surfaces (chat/web) with their exact first-call responses and follow-up steps, expiration times, polling behavior, and the no-card/same-plan immediate-execution paths. It also flags the 'scale' name collision across the two systems and that adding agents doesn't change the bill.

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 dense but every sentence earns its place given the tool's complexity; the retired-plan warning is front-loaded, and the flow details are logically ordered. It could be broken into sections for readability, but it remains appropriately sized.

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?

Given there is no output schema, the description fully compensates by specifying the exact response shapes for each branch (confirmation_required, approval_required, and the immediate-execution cases) and the consent token requirements. It also covers the key edge cases (no card, same plan, expiry) and the warning about the retired system, so an agent has everything needed to invoke it 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?

Schema coverage is 100% and the input schema already comprehensively describes each parameter, including `confirm_token` semantics (single-use, 60s TTL, binding). While the description weaves these into the flow narrative, it adds little beyond what the schema's parameter descriptions already state, so a baseline 3 is appropriate.

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?

States a specific verb ('Moves') and resource ('the caller's org') and precisely defines the target plans (Pro and Scale) with their caps. Explicitly distinguishes itself from Dock's live product (Dock Tokens) and from get_billing's currentPlans, making its purpose unmistakable.

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?

Provides an explicit warning that this is a retired system and should not be offered as current pricing, and points to get_billing's currentPlans as the alternative for live pricing. Also gives concrete direction on selecting `mode`: chat for interactive round-trip, web for headless or click-to-approve flows.

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