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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds material context they cannot convey: the call may reserve and charge existing RQM funds, and it requires human confirmation rather than model-side approval. That financial-irreversibility and consent-gating detail is exactly the kind of behavior an agent must know before invoking; only the absence of retry/queueing semantics keeps it below a 5.

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?

Three sentences, each carrying distinct information: the precondition, the financial consequence, and the consent warning. The precondition is front-loaded, though the opening 'Submit after...' delays the actual action to the end of the clause.

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 a destructive, money-charging, nested-payload tool with no parameter descriptions, the description covers consent and cost but omits what happens after submission (queued job versus immediate execution, polled via get_cloud_motion_status) and how failures or reservations are handled. The presence of an output schema excuses it from explaining return values, but the operational gaps remain.

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 0%, so the description must compensate, and it partly does by mapping the fields to concepts: 'quote' to quote_id, 'stable key' to idempotency_key, and 'trusted human-confirmation receipt' to approval_receipt. It says nothing about the nested request payload (joint angles, target pose, obstacles, robot profile) or about which fields must match the approved quote, leaving half the semantics to the structural 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 verb 'submit' is generic and the resource is only implied by the tool name; the sentence enumerates preconditions ('account, quote, price, request and stable key') rather than stating that a cloud motion-planning job is dispatched. An agent can infer it is a paid, gated submission, but the description alone would not distinguish it from submit_robotics_job without reading the schema.

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 gating condition: submit only after a trusted human-confirmation receipt approves this exact account, quote, price, request and stable key, and it explicitly warns that model approval flags are not consent. It stops short of naming the prerequisite siblings (quote_cloud_motion, get_cloud_motion_approval, resolve_cloud_motion) that an agent would need to call first.

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