Daytrip

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

Goes well beyond annotations: nothing is charged, no personal data needed, price held until expiresAt with re-quote caveat, each call creates a new draft, and call once per confirmed choice. Also documents the full status return vocabulary (handover, price_changed, offer_expired, route_not_available, invalid_input) with recovery actions.

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?

Front-loaded with purpose and handover semantics, and the status enumeration is genuinely useful. It is on the long side and repeats the no-charge/no-booking point in several places, but every section carries actionable information.

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?

With no output schema, the description fully compensates by enumerating return statuses and required agent actions. It covers parameters, error recovery, and behavioral caveats for a non-idempotent, open-world draft-creating tool. Nothing needed to invoke correctly 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?

Schema coverage is 100% so baseline is 3, but the description adds real meaning: distinctions between stops (price known from search) and customStops (re-priced) clarify when to use which array, and it notes the returned price includes stops. This is meaningful value above 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 action (prepare a search_trips option and return a handover link) on a specific resource (daytrip.com booking). It explicitly distinguishes itself from book_trip and search_trips, so an agent can tell it apart from siblings without opening any 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?

Explicitly names when to use it (traveler prefers the website, or book_trip is unavailable) and reinforces what it is not ("It does not create a booking"). The alternative selection is fully specified.

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

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

Annotations declare readOnlyHint/idempotentHint/destructiveHint=false, and the description corroborates rather than contradicts: 'Nothing is reserved and no personal data is needed. Each call prices the trip afresh.' It goes well beyond annotations by disclosing the quote validity window (expiresAt), the re-confirmation requirement when previousPrice is set, and what payload a successful quote returns.

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?

Front-loaded with the core purpose, then a clean status-by-status breakdown that every agent needs. It is on the long side, but nearly every line carries actionable information; only minor trimming is possible.

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?

With no output schema, the description carries the full return-value burden and does so: it enumerates all four statuses, the fields returned on success, and the quote's lifetime. An agent has everything needed to call it and interpret every response.

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 already 100%, so this scores above baseline only for added meaning, and it does add some: it explains that customStops get routed and therefore change the price versus the search, and that invalid_input arises when vehicleType or a stop does not belong to that offer. It does not elaborate on currency/locale/luggage behavior beyond the schema, keeping it at a 4.

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?

Opens with a specific verb + resource ('Price one search_trips option exactly as it will be booked') and explicitly scopes it to the chosen vehicle, party and stops. It names the sibling search_trips as the source of the offer, so an agent can distinguish it from search_trips and get_booking_link immediately.

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?

States the use case (everything the traveler must see before committing) and gives explicit recovery paths per failure mode: call get_quote again after expiresAt, call search_trips again on OFFER_EXPIRED/ROUTE_NOT_AVAILABLE, fix inputs on INVALID_INPUT. It also names the downstream consumer of quoteId (book_trip), so the call is clearly positioned in the flow.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description still adds real substance: prices are per vehicle and all-inclusive, valid until expiresAt, and priceInRequestedCurrency is what checkout actually charges. It also discloses the stops model (priceByVehicle, stopsAllowed, Lite classes being direct) and that only one-way single-vehicle trips are searched. Minor gap: no pagination or result-count expectations, though none appear to apply.

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?

Front-loaded with the one-line purpose followed by a scannable status-by-status breakdown, which suits a tool with six distinct error paths. It is long for a single tool, but nearly every sentence carries operational or customer-facing rules rather than restating 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?

With no output schema, the description fully carries the return-value burden by enumerating the options[] fields (price, capacity, duration, expiresAt, departureAt) and availableStops[] shape. Combined with the error taxonomy and currency rules, an agent has everything needed to call it and act on the result.

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%, so baseline is 3, but the description adds cross-parameter behavior the schema cannot express: party fit is evaluated via fitsPassengers, oversized parties may need two bookings, and the chosen stop list must be forwarded to get_quote/get_booking_link. It also clarifies that vehicle.type is the identifier to pass while vehicle.name is what the customer sees.

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 ('Search Daytrip private door-to-door car transfers') plus the scope ('between two places... bookable prices for every vehicle class'). It also implicitly separates itself from the retrieval siblings by framing search as the entry point that later feeds get_quote and get_booking_link.

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?

Gives an explicit decision tree: call get_quote with offerId and vehicle.type and then book_trip, or get_booking_link for self-serve checkout, plus a per-status recovery instruction for all six outcomes including re-calling search_trips with a candidate label verbatim. It also sets constraints (one-way, single vehicle, larger parties need two bookings).

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