booking

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

Goes well beyond annotations by disclosing fixed pricing tiers, event-date supplements, connection billing (×2), the 12h minimum with a hard 90-minute floor, the LEAD_TIME_TOO_SHORT and FLIGHT_NOT_FOUND error behaviors, and the admin-approval gate on lead_time_override. Annotations only cover the safety profile, so this added operational context is genuinely valuable.

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?

Dense single paragraph, front-loaded with purpose and pricing before routing and error handling. Every sentence carries operational information — no filler or restated field names.

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 mutation tool with nested objects and no output schema, the description covers pricing, location exclusions, error codes, fallbacks, retry/idempotency implications, and override governance. Nothing an agent needs to call it 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 the baseline is 3, but the description adds real meaning beyond the schema: the connection service_type is billed as two services, the transfer object requires a prior get_quote quote_id/vehicle_id, and lead_time_override's precondition is spelled out. Only the pickup_time arrival/departure distinction is already fully covered by 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+resource+artifact: 'Create a secure payment link for a VIP Meet & Greet booking, with optional transfer combo.' It distinguishes itself from siblings by explicitly telling the agent not to call get_quote for the M&G leg, only for the transfer leg.

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?

Rich routing guidance: when to use get_quote (transfer combo only), which locations are valid vs forbidden (Gare du Nord no longer offered), when lead_time_override is permissible, and the exact fallback when the 12h minimum is unmet. Alternatives and preconditions are stated explicitly.

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?

The description discloses critical behavioral details beyond annotations: reservation is gated on payment completion, price is taken from the stored quote rather than passed value, and same idempotency_key returns the same payment link to prevent duplicates. These are not visible in the readOnlyHint/openWorldHint/idempotentHint 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?

The description is three sentences, each earning its place: purpose, prerequisite workflow, and idempotency guidance. It is front-loaded with the core action and avoids redundancy with 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 complex tool with 10 parameters and no output schema, the description covers the essential workflow, payment semantics, and idempotency. It does not describe the return value format, but since no output schema exists and the description otherwise covers decision-relevant behavior, it is sufficiently complete.

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. The description adds meaningful context by explaining that quote_id must come from a prior get_quote call, vehicle_id is chosen from quote results, and price is derived from the quote. It also clarifies idempotency_key behavior beyond the schema's already detailed 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 begins with a specific verb and resource: 'Create a secure payment link to book a private chauffeur transfer.' This clearly distinguishes it from sibling tools like get_quote, get_vehicles, and book_meetgreet.

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?

It gives an explicit required workflow: 'REQUIRED: call get_quote first and pass the resulting quote_id + the chosen vehicle_id.' It also explains that the reservation is created only after payment, and mentions idempotency for retries. However, it does not explicitly state when NOT to use this tool or mention alternatives.

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 the description adds useful context by emphasizing the policy is 'full' and instructing to 'never guess', which signals authoritative data. It doesn't mention side effects, but none are expected for a read-only policy fetch.

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 two short sentences, front-loaded with 'Get' and the resource. Every word adds value—'full' qualifies the scope and 'never guess' provides an actionable guardrail.

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 zero parameters and no output schema, the description fully covers what the tool does and when to use it. The policy content is specified (cancellation, refund, modification), making the tool's purpose unambiguous.

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 tool has zero parameters, so the baseline is 4. The description needs to and does not explain any parameters, which is appropriate. All schema properties are covered (none exist).

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 uses a specific verb (Get) and identifies the exact resource (full cancellation, refund and modification policy). It clearly distinguishes this from sibling tools like book_ride or get_quote by targeting a policy lookup 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?

Explicitly states when to use the tool: 'Use this whenever a customer asks about cancelling, changing, or refunds.' It also provides a clear directive not to guess the policy, giving the agent a rule for when to rely on this tool.

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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the 15-minute quote_id validity, the price-locking behavior, and the OUTSIDE_PARIS_REGION refusal with the prescribed escalation fallback. These are non-obvious operational traits an agent must know before invoking.

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-loads what the tool does and returns, then the sequencing rule, then the gate — a logical order with each sentence earning its place. It is dense (the IMPORTANT/COVERAGE GATE blocks read as policy text) but no sentence is filler.

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 still tells the agent what comes back (all-vehicle prices plus a quote_id). Combined with the ordering requirement and the out-of-coverage refusal path, an agent has everything needed to call it correctly.

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 the baseline is 3. The description reinforces the dd/mm/yyyy format for pickup_date and hints at channel-dependent behavior via the coverage gate, but adds little parameter meaning the schema does not already provide.

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 ('Calculate the exact price for a private chauffeur transfer') and immediately clarifies the output: prices for all vehicles plus a quote_id. This distinguishes it cleanly from siblings like book_ride and get_vehicles.

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?

Explicit sequencing rule ('Always call this before book_ride and pass the quote_id to book_ride'), plus an explicit when-not case: trips outside the Paris region must not be priced and should be escalated instead. Both the happy path and the exclusion are stated with no inference required.

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 the description aligns by saying 'Get information.' It adds useful context about the specific domains covered (coverage areas, airports, policies), going beyond the annotation. It does not describe response structure or limitations, but the readOnly hint lowers the burden.

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?

Two concise sentences with front-loaded action and resource. The second sentence adds practical usage guidance without redundancy. Every word serves a purpose.

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 tool is simple (no parameters, no output schema) and the description covers its purpose, content domains, and intended use case. Combined with clear annotations, it is fully adequate for an agent to select and invoke it.

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 tool has zero parameters, so the schema already fully describes them (baseline 4). The description adds no parameter-level detail, but none is needed.

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 uses a specific verb ('Get information') with a clear resource ('MyDriverParis services, coverage areas, airports served, and policies'). It distinctly separates this from sibling tools like book_ride or get_quote by focusing on general service facts.

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?

It explicitly states when to use the tool ('Use this to answer customer questions'), providing clear context. However, it does not mention when not to use it or name alternative tools, stopping short of full exclusion 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, establishing this as a safe read operation. The description adds useful context by noting it returns capacity and base rates, which goes beyond the annotation. No contradiction exists.

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 just two sentences, front-loaded with the action and resource. Every word earns its place, with no redundant information or filler.

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 tool's simplicity (0 parameters, read-only, clear annotations), the description is largely complete. It conveys the main purpose, usage context, and the key data returned (capacity, base rates). Minor omissions like ordering or availability semantics are not critical at this complexity level.

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 tool has zero parameters, so the description does not need to explain parameter syntax or meaning. The baseline of 4 applies per the rubric for parameterless tools, and no parameter-related gaps exist.

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 it 'List all available vehicles with capacity and base rates.' The verb 'List' plus the resource 'vehicles' and specific attributes clearly distinguish it from sibling tools like book_ride, get_quote, and resolve_flight.

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 says 'Use this to help the customer choose the right vehicle for their trip,' providing clear when-to-use context. It does not explicitly mention alternatives to avoid, but the sibling tools are all different operations, making the intended use 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses substantial behavior not visible in structured data: automatic codeshare resolution with the marketing_flight/operating_flight distinction and the instruction to track the OPERATING flight, tolerant input normalization with concrete examples, and the array return shape with cardinality behavior ('usually 1 when direction is set'). No contradiction with the annotations exists; 'resolve' is consistent with readOnlyHint=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 description is dense — roughly five distinct pieces of information across four sentences — but every sentence earns its place: purpose, codeshare behavior, usage routing, input tolerance, return shape. It is front-loaded with the core function before edge-case behaviors, though the codeshare segment could arguably be trimmed for brevity.

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 present, the description correctly takes on the burden of explaining the return value: array of matching operations, the codeshare:true shape, and the operating_flight field. It also covers date/direction semantics relevant for correct pickups and dropoffs. For a read-only resolver with three well-documented params, nothing an agent needs to call it 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 description coverage is 100%, so the schema already documents flight_number format tolerance, the YYYY-MM-DD date requirement with its dd/mm/yyyy warning, and the direction enum/default. The description adds contextual rationale (pickup/dropoff semantics for date and direction) but does not reveal anything about the parameters themselves beyond what the schema provides, so the baseline of 3 is appropriate.

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 first sentence names a specific verb and resource ('Resolve a flight number') and lists the concrete outputs (airports, terminals, scheduled times, status). It clearly differentiates from sibling resolvers like resolve_train and resolve_location while sharing the resolve_* naming pattern.

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 states when to invoke it: 'Use BEFORE book_ride whenever the customer provides a flight number', naming the downstream sibling and the motivating reason (correct pickup time and terminal). The airline/airport domain context is unambiguous, leaving no ambiguity about when this prevents errors.

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 openWorldHint=true, so the safety profile is covered. The description adds valuable context: it returns up to 5 candidates, includes place_id/address/type hint, and calls out that include_coords triggers an extra API call only when needed. This goes beyond the annotations without contradicting them.

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 a single dense paragraph that front-loads the purpose and includes concrete examples ('CDG', 'Le Bristol', 'Gare du Nord'), while covering usage guidance, output shape, and option behavior without wasted words.

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 adequately explains return values (up to 5 candidates with place_id, address, type hint, optional coordinates) and the optional coords behavior. It lacks edge-case handling like no-match results, but for this tool's scope it is substantially complete.

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 the parameters are fully documented in the schema with examples and default behavior. The description reinforces the query format and the extra-API-call implication of include_coords, but it does not add substantial new parameter-level meaning beyond what the schema already provides.

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 uses a specific verb ('Resolve') and resource ('free-text location... to a canonical address + coordinates'), and clearly differentiates from sibling tools like resolve_flight and resolve_train by focusing on geocoding for bookings. It explicitly lists concrete inputs (city, airport, hotel, station, full address) and outputs, making its purpose unambiguous.

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?

It explicitly advises 'Use this BEFORE get_quote when the customer gives a fuzzy pickup/drop-off', which provides clear situational guidance. It does not explicitly contrast with resolve_flight/resolve_train, but the tool names and context make those distinctions implicit, so it falls just short of a 5.

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 set readOnlyHint=true and openWorldHint=true, lowering the burden. The description adds useful behavioral context: it uses the official SNCF API, covers a wide range of train types, and explicitly states what cannot be looked up (PNRs, agency refs). This goes beyond the annotations without contradicting them.

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, front-loaded with the core function. The content is dense and informative, with no filler. Slightly verbose due to the detailed train coverage and exclusions, but every sentence 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?

Given no output schema, the description adequately notes it returns 'route, stations and scheduled times'. It covers usage scenarios, exclusions, coverage, and what not to do, making it fully self-contained for an agent to decide when and how to invoke the tool.

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% for both parameters, so baseline is 3. The description adds meaningful semantics by explaining train number formats with examples, emphasizing digits-only with optional prefixes, and clarifying that 6-char codes and long refs are not valid inputs — enriching the schema 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 the verb+resource: 'Resolve a TRAIN NUMBER to its route, stations and scheduled times'. It is specific to train numbers and distinguishes itself from siblings like resolve_flight and resolve_location by covering rail travel and explicitly enumerating train operators.

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 usage context: use when a customer books a station pickup/drop-off or Meet & Greet and gives a train number to verify times. It also gives clear exclusions by identifying PNR and agency booking references as invalid, directing the agent to extract info from the customer's confirmation instead.

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 readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context: that this is a side-effectful email send, the email lookup fallback to WP, and the return shape { sent, to (masked), client_phone }. This goes beyond what annotations provide.

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 compact sentences, front-loaded with the main purpose, followed by conditional usage, return value, and audience. No wasted words; each sentence 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?

The description is complete for a moderate-complexity tool with 6 params and no output schema. It explains the action, the email fallback, the return format, and the intended voice-agent context. It relies on schema for individual param details, which is acceptable.

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 each parameter has a description. The tool description adds meaning especially for `email`, explaining when to supply it and when it is auto-looked-up. It also clarifies that `driver_first_name` should be first name only (echoed from schema). This is useful 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 explicitly states 'Email the booking's client their assigned driver's first name + phone', which is a specific verb+resource+scope. It distinguishes this tool from sibling tools (none of which send emails) and adds a clear use-case note ('Voice agent use').

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?

It provides clear conditional guidance: pass `email` if you already have the client's address (e.g., from Zeplan get-booking), otherwise WP looks it up on the booking post. It doesn't explicitly state when not to use the tool, but the context and sibling list make the usage scenario clear.

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