firestarter_assist_book

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

Even though annotations already indicate this is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), the description adds crucial behavioral details: dispatching a real crew, charging the fee to the buyer's order, and automatically starting the escrow inspection window upon proof-of-delivery photo. These real-world consequences and automated side-effects go well beyond the annotations, providing high transparency.

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 three sentences, each earning its place. The first states the core purpose, the second delivers a critical safety condition and real-world consequence, and the third adds an important automated side-effect. No filler or redundancy.

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 tool with significant side-effects, the description covers the key outcomes: real crew dispatch, fee charge, and escrow automation. It does not describe the return value or confirmation behavior, and there is no output schema to fall back on, leaving a minor gap. Overall, it is complete enough for an agent to use it safely and effectively.

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 only 36%, so the description must compensate. It adds context for key parameters: 'from a firestarter_assist_quote result' clarifies quote_ref, 'exact price' relates to fee_cents, and 'Link the purchase execution' explains execution_id. However, it does not mention pickup/dropoff addresses or contact parameters, though these are self-explanatory by name. The description adds value but does not fully compensate for the low schema coverage.

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 a specific verb and resource: 'Book a courier from a firestarter_assist_quote result.' This clearly states the action and its input source, and it distinguishes this tool from siblings like firestarter_assist_quote (which generates quotes) and firestarter_confirm_delivery (which likely confirms after courier action). The additional context about linking purchase execution further clarifies its unique role.

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?

The description explicitly states when to use the tool: 'ONLY call after the human has explicitly confirmed the exact price.' This is a strong condition that prevents misuse. It also gives guidance on linking the purchase execution when present. However, it does not name alternative tools or explicitly say when not to use it beyond the price confirmation gate, so it falls short of a perfect 5.

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