cancel_deliveryCancel a booking before pickup — the full posted price releases back to the Wallet. After pickup the trip stays charged and the call is refused. Safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| delivery_id | Yes | ||
| robomart_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the financial consequence ('full posted price releases back to the Wallet'), the post-pickup refusal behavior, and retry safety. These go beyond the annotations and align with idempotentHint=true, with no contradiction.
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 short sentences are front-loaded with the action, and each sentence adds distinct information: action window, financial outcome, and retry behavior. There is no filler or repetition of the schema.
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 one-required-parameter cancellation tool, the description plus schema and annotations cover all invocation essentials: action, precondition, refund effect, refusal, and idempotency. The lack of an output schema is not a significant gap for this operation.
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 description does not mention delivery_id or robomart_version at all, and schema description coverage is 0%, so there is no parameter-level compensation. The generic word 'booking' does not add meaning beyond the already self-descriptive delivery_id property.
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 opens with the verb 'Cancel' and the object 'a booking', clearly identifying a delivery-cancellation action before pickup. The temporal qualifier 'before pickup' sharpens the scope and distinguishes it from siblings like book_delivery, track_delivery, and get_proof.
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?
'Before pickup' states an explicit precondition, and 'After pickup ... the call is refused' provides a clear when-not condition. It does not explicitly name alternatives among the sibling tools, but cancellation is semantically distinct enough from booking, coverage, proof, and tracking that the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action in the delivery lifecycle: coverage lookup, booking, cancellation, tracking, and proof retrieval. There is no meaningful overlap or risk of an agent selecting the wrong tool.
All tool names follow a consistent verb_noun snake_case pattern: book_delivery, cancel_delivery, check_coverage, get_proof, track_delivery. The verbs are specific and the pattern is predictable.
Five tools is well-scoped for a delivery booking server. Each tool covers a necessary step or read operation without redundancy or bloat.
The tool surface covers the full delivery workflow: pre-booking coverage check, booking, cancellation, live tracking, and completion proof. There are no obvious dead ends or missing critical operations.