RIED.TAXI

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

The description adds meaningful behavioral context beyond the annotations: cancellation is free of charge, must happen before pickup, requires customer_confirmed=true after explicit customer confirmation, and cannot be undone. These details are not present in the annotations or schema and materially shape how and when the tool should be used.

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 compact and front-loaded: the first sentence states the core behavior and key constraints, followed by a concise list of prerequisites and the irreversible nature of the action. There is no redundant or filler language.

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 the annotations, output schema presence, and the relatively simple cancellation semantics, the description covers all critical operational aspects: what happens, when it can happen, prerequisites, costs, and irreversibility. No essential information for invoking the tool 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?

The description reinforces which parameters are essential and adds the crucial semantic that customer_confirmed must be set to true only after the customer explicitly confirms. Schema descriptions already cover access_code, idempotency_key, and booking_reference, but the optional 'reason' parameter is not explained. The description partially compensates for the coverage gap by emphasizing the required confirmation flow.

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 clearly states the action ('Cancels a booking') and identifies the specific resource. The addition of 'free of charge, any time before the pickup' distinguishes this cancellation operation from the sibling update/get/hold tools. An agent can immediately tell this tool is for canceling, not modifying or retrieving.

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 gives explicit usage context: cancellation is possible any time before pickup and requires customer confirmation before the flag is set true. It does not explicitly name alternative tools or list exclusions, but since no sibling is a cancellation tool, the primary use case is unambiguous.

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 declare read-only, idempotent, and non-destructive behavior, and the description adds valuable context beyond that: it checks the real calendar including temporary holds, depends on the whole day due to one car/driver, returns alternatives when unavailable, and clarifies that availability is not a reservation. This is rich behavioral disclosure 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 sentences deliver the essential scope, caveats, and return behavior with no wasted words. The most important information about the real calendar and read-only nature is front-loaded.

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?

The description covers the key behavioral and usage context: real calendar, capacity constraint, read-only semantics, and alternatives on failure. Since an output schema exists, return values are already specified; however, it does not clarify how optional addresses affect the drive-time calculation, which is a minor completeness gap.

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 40%, covering pickup_date and pickup_time, while passengers, pickup_address, and destination_address are undocumented in the schema. The description mentions driving to the pickup and back, which hints at address importance, but it does not explain any of the undocumented parameters or their role in the availability calculation.

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 clearly states the tool checks RIED.TAXI's real calendar for availability, which is a specific verb and resource. It distinguishes itself from booking/management siblings by emphasizing it is read-only and not a reservation, though it does not explicitly name alternative tools.

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 gives clear context: availability is whole-day dependent and a free result is not a reservation, so an agent knows not to treat this as a booking action. It does not explicitly state when to prefer this over get_quote or hold_booking, but the read-only clarification provides useful boundary guidance.

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true), the description adds that the call 'blocks the day' and that 'retrying with the same key never creates a second booking', elaborating on the idempotency guarantee. It also discloses the return of 'the booking reference and an access code'.

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, front-loaded with the core action, and each sentence adds essential information (action, condition, requirement, return). No redundant phrases.

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 25-parameter tool with an output schema, the description covers the critical gating and side-effect information. It does not explain all required fields, but the schema already documents many, and the description focuses on the conditions that are easy to get wrong. The main gap is lack of guidance on which parameters are mutually exclusive or required only for airport pickups, but that is partially in the schema.

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 52%, so the description should compensate for under-documented parameters. The description highlights quote_id, customer_confirmed, accepted_terms, and idempotency_key but does not add meaning to the many unannotated parameters like first_name, last_name, or pickup_address. The idempotency_key explanation adds value, but overall the description adds minimal parameter-level detail.

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 states a specific action: 'Creates a REAL, CONFIRMED booking in RIED.TAXI's booking system and blocks the day.' This clearly differentiates from siblings like get/cancel/update/hold by emphasizing the confirmed creation action and its side effect.

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 gives an explicit condition: 'Only call after the customer has seen the complete trip and price and explicitly said yes.' It also lists required prerequisites (quote_id, customer_confirmed, accepted_terms, idempotency_key), but it does not explicitly name sibling tools or state when to prefer an alternative such as hold_booking.

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 declare readOnlyHint=true and idempotentHint=true, so the description's 'Read-only' is redundant. It adds minor behavioral context like the access code being customer-received and the specific data fields returned, but these are largely covered by the output schema and parameter schema. No contradiction with annotations.

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, well-structured sentences with no fluff. The purpose is front-loaded, followed by requirements, and a final read-only note. Every sentence contributes directly to correct invocation.

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?

This is a simple single-booking lookup with only two parameters, both fully specified in the schema, and an output schema exists to describe return structure. The description covers the operation's purpose, required inputs, and read-only nature. Nothing an agent needs for correct invocation 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 description coverage is 100%, so both parameters (booking_reference and access_code) are already well-documented with formats and examples. The description adds only a slight clarification that the access code was received by the customer, which already appears in the schema ('given at booking time'). No significant additional meaning beyond 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?

The description clearly states a specific verb ('Returns'), a resource ('ONE booking'), and the scope of what is returned (status, pickup time, addresses, price, flight). It distinguishes itself from siblings like cancel/create/hold/update by focusing on retrieval only.

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 makes it clear this is for looking up a booking and is read-only, implying it is not for modifications. However, it does not explicitly name alternative tools (e.g., ried_taxi_update_booking) or state when not to use it. The context is clear but exclusions are only implicit.

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 declare readOnlyHint, idempotentHint, and destructiveHint, so the bar for added context is lower. The description still adds substantial behavior beyond those annotations: quote_id is valid for 30 minutes, status values are enumerated, resolved pickup/destination should be shown to the customer, and ambiguous_place requires re-prompting with a postcode.

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 compact and front-loaded, starting with the core function and read-only safety. There is minor redundancy — 'Returns' opens two sentences and 'read-only' restates an annotation — but every sentence otherwise earns its place.

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 rich annotations and an output schema, the description covers the essential operational details: quote validity, status values, how to present resolved addresses, and how to handle ambiguous places. It does not explain what to do for manual_quote_required or not_offered, though those states are reasonably self-explanatory.

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 only 50%, and the description does not compensate for the undocumented parameters. It offers little input-side guidance beyond hinting that a postcode resolves ambiguity, while large_suitcases, flight_number, special_requirements, and passenger constraints remain unexplained in both schema and description.

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 clearly states a specific verb ('Returns') and resource ('RIED.TAXI's current price for one journey'), and identifies the backend as the only valid price source. It also explicitly distinguishes the tool from booking or reserving, which separates it from sibling tools like ried_taxi_create_booking and ried_taxi_hold_booking.

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 read-only framing and 'never books or reserves anything' make it clear this tool is for price lookup, not booking. It also gives a concrete conditional instruction for ambiguous_place — ask the customer and resend with the postcode — though it does not explicitly name sibling alternatives or state when to use them.

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 indicate the operation is not read-only, not idempotent, and not destructive)Skip the description adds valuable context: the hold is temporary, expires automatically, and blocks other customers or assistants for 15 minutes. This goes beyond what the annotations can convey.

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 deliver the key facts up front: what the hold does, its duration, its exclusivity, automatic expiry, and when to call. No filler or repetition of schema details.

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?

The description is complete for an agent deciding whether and when to call. It explains the purpose, duration, expiration behavior, and relationship to the booking flow, while the output schema handles return details.

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 67%, with pickup_date and pickup_time already documented with formats and timezone. The description does not explicitly explain how quote_id maps to the 'quoted date' it mentions, leaving quote_id somewhat underspecified beyond its name.

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: 'Temporarily reserves the quoted date for THIS customer for 15 minutes.' It clearly distinguishes itself from create_booking by explicitly saying 'Not a booking,' and the exclusivity detail removes ambiguity about what the hold accomplishes.

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?

Provides explicit when-to-use guidance: 'Call after availability is confirmed and the customer wants to proceed.' It also communicates what this tool is not for with 'Not a booking,' which helps the agent avoid using it as a final booking operation.

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?

Beyond the annotations, the description discloses the two-phase preview/apply workflow, idempotency key requirement, and the human-approval path (sent to Ronald, status change_requested). This adds meaningful side-effect and state-transition context consistent with readOnlyHint=false and idempotentHint=true.

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 three sentences are dense and purposeful: the mandatory call sequence is front-loaded, and the follow-up sentences spell out the key behavioral outcomes. No filler or redundant repetition of schema details.

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 complex two-phase mutation with approval routing, the description supplies the complete call pattern, idempotency guidance, and immediate-vs-deferred outcomes. Since an output schema exists, not needing to describe return values does not leave a gap.

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?

With 50% schema coverage, the description compensates by explaining mode semantics)Skip: it clarifies which change types are allowed immediately (flight number, passengers max 5, notes, addresses) and which require approval (new date or different price). It does not enumerate all nested fields, but the schema already provides descriptions for several of them.

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 states the specific action ('Changes a booking') and the exact resource, which clearly distinguishes it from create, cancel, get, hold, and quote siblings. The preview/apply modes further define the tool's unique purpose.

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 gives explicit usage instructions: always call with mode='preview' first, show the result, then call with mode='apply', customer_confirmed=true, and an idempotency_key. It also specifies which changes apply immediately and which require approval, but it does not explicitly discuss alternatives or exclusions.

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