booking

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

No annotations provided, so description carries full burden. It discloses behavioral traits: returns specific errors (LEAD_TIME_TOO_SHORT, FLIGHT_NOT_FOUND), idempotency behavior, connection pricing (×2), and interplay between flight_unverified and manual_airline/manual_origin. However, it doesn't explicitly state that it's a write operation creating bookings, though implied.

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 core purpose. While every sentence adds value, it could benefit from minor restructuring (e.g., separating pricing, error handling) for easier consumption. It remains clear and actionable for an AI agent.

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 complexity (24 params, nested object, no output schema), the description covers pricing, errors, combo behavior, and fallback procedures. However, it lacks explicit mention of successful output structure (e.g., payment_url) and how to handle the response beyond errors.

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% (baseline 3). The description adds significant meaning beyond schema: pricing tables per location, connection billing (×2), combo transfer requirements ( quote_id+vehicle_id from get_quote), and conditional parameters (flight_unverified requires manual_origin/manual_airline). This greatly enriches 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 clearly states the tool creates a secure payment link for VIP Meet & Greet, with optional transfer combo. It explicitly distinguishes from get_quote by warning not to call it for the M&G part, and mentions fixed pricing per location. Sibling tools like book_ride imply different purposes.

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 explicit when-to-use and when-not: 'do NOT call get_quote for the M&G part' and 'For a combo with a transfer... call get_quote first'. It also specifies error handling actions for LEAD_TIME_TOO_SHORT and FLIGHT_NOT_FOUND, guiding the agent on fallback behavior.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the reservation is created automatically only after payment completion, price is taken from the stored quote, and idempotency_key usage for safe retries. However, it doesn't cover all potential behavioral aspects like error handling or response format, leaving some gaps.

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 front-loaded with the core purpose, followed by critical usage notes and behavioral details. Every sentence adds essential information—no wasted words. It efficiently covers prerequisites, payment flow, and idempotency in a compact format.

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 complexity of a booking tool with 10 parameters and no output schema, the description does well by explaining the payment flow, prerequisites, and idempotency. However, it lacks details on the response format (e.g., what the payment link looks like) and error scenarios, which could be important for an AI agent.

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 all parameters thoroughly. The description adds minimal semantic value beyond the schema, such as emphasizing that quote_id and vehicle_id come from get_quote and that price is from the stored quote. This meets the baseline of 3 when schema coverage is high.

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's purpose: 'Create a secure payment link to book a private chauffeur transfer.' It specifies the action (create payment link) and resource (private chauffeur transfer booking), distinguishing it from sibling tools like get_quote (which provides quotes) or 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?

The description provides explicit usage guidelines: 'REQUIRED: call get_quote first and pass the resulting quote_id + the chosen vehicle_id.' It also specifies when not to use it (e.g., without a valid quote) and mentions alternatives implicitly by referencing get_quote as a prerequisite, though it doesn't explicitly list all sibling tools.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the quote_id validity period ('valid for 15 minutes'), the price-locking mechanism ('locks the price and prevents drift'), and the mandatory call sequence. However, it doesn't mention error conditions, rate limits, or authentication requirements, leaving some gaps.

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 efficiently structured with zero wasted sentences. It front-loads the core purpose, immediately follows with critical behavioral information (quote_id validity and book_ride relationship), and ends with the most important parameter constraint. Every sentence earns its place by providing essential guidance.

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 8 parameters, no annotations, and no output schema, the description provides strong contextual completeness regarding purpose, usage sequence, and key behavioral constraints. However, without an output schema, it doesn't describe the return structure beyond mentioning 'prices for all available vehicles' and 'quote_id', leaving the exact response format unspecified.

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 all 8 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - only reinforcing the format requirement for pickup_date ('must be in dd/mm/yyyy format'), which is already stated in the schema. This meets the baseline expectation when schema coverage is complete.

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's purpose with specific verbs ('calculate', 'returns') and resources ('price for a private chauffeur transfer', 'prices for all available vehicles', 'quote_id'). It distinguishes from siblings by explicitly mentioning the relationship with book_ride and contrasting with get_vehicles (which presumably lists vehicles without pricing).

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 explicit usage guidelines: 'Always call this before book_ride' establishes a mandatory sequence, 'pass the quote_id to book_ride' specifies the required parameter flow, and 'it locks the price and prevents drift' explains the functional benefit. This clearly differentiates when to use this tool versus alternatives like book_ride or get_vehicles.

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?

No annotations are provided, so the description carries full burden. It states the tool gets information, implying a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or response format. The description is minimal and lacks essential operational context for a tool with no structured 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 appropriately sized and front-loaded. The first sentence states the purpose, and the second provides usage context. Both sentences earn their place with zero wasted words, making it efficient and well-structured.

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, no output schema, no annotations), the description is complete enough for basic understanding. It covers purpose and usage context. However, without annotations or output schema, it lacks details on response format or behavioral constraints, which could be important for an AI agent to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage (empty schema). The description adds no parameter information, which is appropriate since there are no parameters. Baseline for 0 parameters is 4, as the description doesn't need to compensate for missing param 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 clearly states the tool's purpose with a specific verb ('Get') and resource ('information about MyDriverParis services, coverage areas, airports served, and policies'). It distinguishes from siblings by focusing on informational retrieval rather than booking, quoting, or resolving operations. However, it doesn't explicitly differentiate from potential informational siblings like '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?

The description provides clear context for usage: 'Use this to answer customer questions.' This gives a specific scenario when to use the tool. It doesn't explicitly state when not to use it or name alternatives among siblings, but the context is sufficiently clear for a read-only informational 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it indicates this is a read operation ('List'), it doesn't specify whether this requires authentication, rate limits, pagination behavior, or what the return format looks like (e.g., JSON structure). For a tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond its basic purpose.

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 highly concise and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and usage. The first sentence states what it does, and the second provides context for when to use it, with no wasted words or redundant 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?

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and basic usage but lacks details on behavioral aspects like authentication needs or return format. Without annotations or an output schema, the description should ideally provide more context on what the output looks like (e.g., 'returns a list of vehicles with fields for capacity and base rates') to be fully 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?

The input schema has 0 parameters with 100% coverage, meaning there are no parameters to document. The description appropriately doesn't discuss parameters, which is correct for a parameterless tool. It adds value by clarifying the tool's output includes 'capacity and base rates,' which isn't captured in the schema since there's no output schema provided.

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's purpose with a specific verb ('List') and resource ('all available vehicles'), and includes additional details about what information is provided ('capacity and base rates'). It distinguishes itself from siblings like 'book_ride' or 'get_quote' by focusing on vehicle listing rather than booking or pricing. However, it doesn't explicitly differentiate from potential similar listing tools that might exist in other contexts.

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 implied usage guidance by stating 'Use this to help the customer choose the right vehicle for their trip,' which suggests this tool is for pre-booking vehicle selection. However, it doesn't explicitly state when to use this versus alternatives like 'get_quote' (which might provide pricing) or 'get_service_info' (which might provide broader service details), nor does it mention any exclusions or prerequisites for use.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: input tolerance (accepts various flight number formats with internal normalization), output format (returns an array of matching operations), and typical result (usually 1 match when direction is set). However, it lacks details on error handling or rate limits.

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 efficiently structured in three sentences: purpose, usage guideline, and behavioral details. Each sentence adds critical information without redundancy, making it front-loaded and easy to parse for an AI agent.

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 moderate complexity (3 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, input behavior, and output format. However, it lacks explicit error scenarios or authentication requirements, which could be relevant for a flight resolution 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 description coverage is 100%, so the baseline is 3. The description adds value by explaining input tolerance for 'flight_number' ('accepts 'AF007', 'AF 007', 'AF-007', 'af7', 'AFR007' — the tool normalizes internally'), which goes beyond the schema's generic description. It also clarifies the typical output behavior related to parameters, though it doesn't detail all parameters.

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's purpose: 'Resolve a flight number to its airports, terminals, scheduled times, and status.' It specifies the verb ('resolve') and resource ('flight number'), and distinguishes it from siblings like 'book_ride' by focusing on flight information retrieval rather than booking or other services.

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 explicit guidance on when to use this tool: 'Use BEFORE book_ride whenever the customer provides a flight number so that pickup time and terminal are correct.' It names a specific alternative ('book_ride') and clarifies the context (pre-booking for accurate pickup details).

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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it uses 'the same geocoder that Zeplan consumes for bookings' (context on data source), returns 'up to 5 candidates' (output limit), and mentions optional coordinates with an 'extra API call' (performance implication). However, it lacks details on error handling or rate limits, preventing a perfect score.

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 front-loaded with the core purpose in the first sentence, followed by usage guidelines and output details. Each sentence adds essential information—such as workflow placement, examples, and behavioral traits—with zero waste, making it efficient and well-structured for quick comprehension.

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 annotations and no output schema, the description does a strong job covering purpose, usage, and key behaviors. It explains the output format ('place_id, full address, type hint, and optionally coordinates') and limits ('up to 5 candidates'), compensating for the lack of structured fields. However, it omits details like error cases or authentication needs, leaving minor gaps in completeness.

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 both parameters thoroughly. The description adds value by explaining the tool's purpose with 'free-text location' and providing context for 'include_coords' ('extra API call' and 'request only when the agent has picked the right candidate'), enhancing understanding beyond the schema. Since parameters are documented, baseline is 3, but the added context justifies a higher score.

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 specific action ('resolve'), resource ('free-text location'), and transformation ('to a canonical address + coordinates'). It explicitly distinguishes from sibling tools by stating 'Use this BEFORE get_quote' and provides concrete examples of fuzzy inputs like 'CDG', 'Le Bristol', and 'Gare du Nord', making the purpose unambiguous and distinct.

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 explicit guidance on when to use this tool ('BEFORE get_quote when the customer gives a fuzzy pickup/drop-off') and includes examples of appropriate inputs. It also distinguishes from alternatives by specifying its role in the workflow relative to 'get_quote', offering clear context for selection without misleading exclusions.

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 no annotations, the description carries the full burden. It explains the return format { sent, to (masked), client_phone } and the conditional lookup. However, it does not disclose potential side effects, idempotency, or rate limits. This is adequate but not comprehensive for a send action.

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 sentences with an additional short note. It efficiently communicates the core action, conditional logic, return values, and usage context. No unnecessary 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?

Given 6 parameters (3 required) and no output schema or annotations, the description covers the main flow: what it does, when to provide email, and what it returns. It lacks error conditions or permissions, but for a straightforward email tool, it is largely 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 description coverage is 100%, so the schema already explains each parameter. The description adds context for the `email` parameter (lookup logic) and reiterates the constraint on `driver_first_name` (FIRST NAME only). This adds marginal value 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 the verb 'Email' and the resource 'the booking's client their assigned driver's first name + phone'. It specifies the action and includes return value details. The tool is distinct from siblings like book_meetgreet or book_ride, which are different operations.

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 guidance on when to include the `email` parameter ('if you already have the client's address') and when to omit it ('otherwise WP looks it up'). It also mentions 'Voice agent use', giving context. However, it does not explicitly state when not to use the tool or compare with alternatives.

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