booking

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

Even though annotations already indicate this is a non-read-only, non-destructive mutation, the description goes far beyond by disclosing error codes (LEAD_TIME_TOO_SHORT, FLIGHT_NOT_FOUND), fixed pricing rules, the 12-hour lead time with override conditions (requiring explicit admin approval), and the 90-minute hard floor. This is directly useful behavioral context not available in 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 a single dense block but every sentence carries essential operational information. It is front-loaded with the core purpose. The lack of bullet points or section breaks makes it harder to digest quickly, but given the complexity (25 params, nested objects), this level of detail is justified.

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 complexity (25 params, nested transfer object, multiple error modes, pricing rules), the description covers all critical aspects: location availability, pricing, connection billing, transfer combo flow, lead time handling, override conditions, and flight validation failure. There is no output schema, but the description still communicates return error codes, which is sufficient for successful invocation.

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%, but the description adds crucial meaning beyond the schema: pricing formulas for M&G and connections, how transfer combos should be built (get_quote first, pass quote_id and vehicle_id), the semantics of pickup_time for departures, and the approval requirement for lead_time_override. This materially improves parameter understanding.

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 action and resource: 'Create a secure payment link for a VIP Meet & Greet booking, with optional transfer combo.' It clearly distinguishes this from siblings like book_ride and get_quote by stating the purpose (booking M&G) and the optional combo. The scope (locations, exclusions) is also explicit.

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 provides extensive when-to-use guidance: available locations, explicit exclusion of Gare du Nord, instruction to avoid get_quote for M&G, procedure for connection and transfer combos, and fallback behavior for lead time or flight validation errors. It clearly names alternatives (get_quote) and 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?

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?

Annotations declare readOnlyHint=true, so the agent already knows it's a safe read. The description adds critical behavioral context: quote_id is valid for 15 minutes, the price is locked, and pickup_date must be dd/mm/yyyy. 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 sentences: purpose+returns, usage workflow, format warning. Each sentence earns its place, front-loads the core 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?

Despite no output schema, the description tells the agent exactly what is returned (prices for all vehicles, quote_id) and how to use it downstream. With an 8-parameter schema fully covered, this is complete for successful invocation.

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 only repeats the dd/mm/yyyy format already in the schema, adding no new parameter semantics beyond that.

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 the verb 'Calculate' with a specific resource 'exact price for a private chauffeur transfer' and states it returns prices for all available vehicles and a quote_id. It clearly differentiates from book_ride (which consumes the quote_id) and get_vehicles (which lists 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?

Explicitly states 'Always call this before book_ride and pass the quote_id to book_ride', defining the exact pre-condition and workflow. It also explains the benefit (locks price, prevents drift), giving the agent clear guidance on when to invoke.

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?

With readOnlyHint and openWorldHint annotations already set, the description adds valuable behavioral context: tolerant input formats, internal normalization, and a return shape ('array of matching operations, usually 1 when direction is set'). This goes beyond simple safety flags to clarify expected behavior and edge cases.

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 concise sentences, front-loaded with the core purpose, followed by usage guidance and input/return nuances. Every sentence earns its place; no fluff or redundant restatement of the name or title.

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?

Despite lacking an output schema, the description adequately explains the return type ('array of matching operations') and key fields resolved. It covers purpose, usage, input tolerance, and edge cases, making it sufficiently complete for an AI agent to select and invoke the tool 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 coverage is 100%, with each parameter already well-described. The description adds extra clarity by noting format tolerance and normalization behavior for flight_number, and implies that direction affects result count, which enriches understanding without repeating schema details.

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 clearly identifies the resource and outputs: airports, terminals, scheduled times, and status. It distinguishes itself from sibling tools like resolve_train and resolve_location by focusing on flight numbers.

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 instructs to 'Use BEFORE book_ride whenever the customer provides a flight number', which is a clear when-to-use directive tied to a sibling tool. It also conveys the context of pickup/drop-off times and terminal correctness, effectively differentiating this tool from 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 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.