cpu_quote_transport

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

No annotations are provided, so the description carries the full burden and succeeds: it declares 'Read-only on-chain view with no side effects,' states it 'reserves no room,' and enumerates concrete rejection conditions (hop-length bounds, ineligible waypoints, endpoint ownership, destination capacity counting liquid/reserved/pending production). It also warns that ownership, balances, capacity, pauses, allowances and live state can change before the send — exactly the caveat an agent needs before relying on a quote.

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?

Long (~220 words) but front-loaded: the preview-without-commit purpose and return values come first, followed by safety, rejection logic, caveats, and sibling routing in order of descending importance. Every sentence earns its place — there is no filler or restatement of schema content, and the minor redundancy between 'without committing' and 'no side effects' reinforces rather than bloats.

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 no annotations and no output schema, the description fully compensates: it explains the return payload (fee, discount, summed grid distance, arrival timestamp), defines the fee/discount identity, names every rejection category, and clarifies the limited force of a successful quote. Nothing an agent needs to decide whether and how to call the tool is 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?

The schema already documents all three parameters at 100% coverage, so the baseline is 3. The description raises it by adding validation semantics that deepen the path parameter's meaning: Virgin ground and foreign finished Hubs are passage rather than obstacles, destination room counts liquid/reserved/pending production, and the fee/discount relationship clarifies what amount implies economically. No contradiction with the 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?

States a specific verb and resource: 'Preview a transport route (a waypoint chain of tokenIds) without committing,' then lists the concrete return payload (fee, discount, grid distance, arrival timestamp). It distinguishes itself from siblings by contrasting with cpu_transport (which commits) and explicitly naming the planning tools cpu_route_network and cpu_next_hops, so an agent can tell them apart without opening schemas.

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?

Explicitly routes between alternatives: 'Plan the chain with cpu_route_network when you have a code runner and with cpu_next_hops when you do not; use this before cpu_transport.' It also gives a when-not-to-trust boundary by stating the quote reserves no room and does not promise the later cpu_transport will succeed, preventing the agent from treating a successful quote as a guarantee of execution.

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