airport-transfers

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

Despite annotations indicating a write operation, the description adds critical behavioral context: it emails a one-tap confirmation link, the ride is only booked after the passenger confirms, and payment is made directly to the driver with no online payment needed. This goes well beyond the annotations and clarifies side effects and non-finality.

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 focused sentences, front-loaded with the primary purpose, followed by key caveats and a clear usage order. Every sentence adds value and there is no redundancy.

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 14 parameters and no output schema, the description covers purpose, workflow, and expected passenger experience well. However, it does not mention what the tool returns (e.g., a booking request ID needed for get_booking_request_status), which is a notable gap given no output schema is provided.

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 workflow around some parameters (e.g., passengerEmail receives the confirmation link, routeSlug comes from list_routes) but adds no meaning beyond what the schema already conveys.

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 'Start a provisional airport-transfer booking' and immediately distinguishes it from finalization by noting it does NOT finalize a booking. The verb 'Start' plus the resource 'airport-transfer booking' makes the action specific and 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?

The description explicitly says to call estimate_price first to confirm vehicle and price, then call this tool. It also instructs to always tell the user to check their email, providing clear when-to-use guidance and a concrete prerequisite.

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=true, the description adds meaningful behavior beyond annotations by specifying it returns the cheapest vehicle plus all fitting options. This sets expectations for the output without needing an output schema. No contradictions 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 sentences that front-load the purpose, then detail inputs and behavior. No redundant words or filler. Every sentence adds value.

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 3 parameters and no output schema, the description adequately explains the return value (cheapest vehicle + all fitting options) and usage context. Could mention edge cases like vehicle unavailability, but is complete enough for typical use.

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 has 100% coverage with descriptions for all three parameters. The description reinforces how route, passenger count, and optional luggage are used, but does not add new meaning beyond the schema. Baseline 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 description clearly states the tool estimates trip prices and returns the cheapest vehicle fitting the group, with a concrete example ('how much for N people from X to the airport?'). This distinguishes it from sibling tools like get_pricing by emphasizing the recommendation aspect (cheapest option).

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 guidance on when to use it (answering price queries for a route and group size) and references list_routes for routeSlug. Does not explicitly exclude alternatives like get_pricing, but the usage context is clear enough for an agent to decide.

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 goes beyond the readOnlyHint annotation by specifying the exact return values ('pending', 'confirmed' with booking number, 'expired') and explaining the dependency on passenger confirmation. This adds useful behavioral context not available from annotations alone.

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 the primary purpose followed by the return values. Every sentence contributes essential information, with no 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?

For a simple read-only status-check tool with one parameter and no output schema, the description fully covers the tool's behavior and return values. It also ties the requestId to its origin (create_booking_request), making it self-contained and 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 schema already fully describes requestId as 'The requestId returned by create_booking_request.' The description repeats this same context without adding new details about formatting, constraints, or examples. With 100% schema coverage, baseline 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 description clearly states the tool checks booking request status, with a specific verb and resource ('booking request from create_booking_request'). It distinguishes itself from siblings by focusing on the status of a previously created request, rather than pricing or route info.

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 implies the tool should be used after calling create_booking_request, since it expects a requestId from that tool. It provides clear context for when to use it but does not explicitly name alternatives or exclusions, so it falls 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 declare readOnlyHint=true and openWorldHint=false, so the description adds value by specifying the output includes prices in EUR and RSD, and that each vehicle tier lists max passengers and luggage. It also clarifies the fixed-price nature. 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 two sentences with front-loaded purpose and no redundant wording. Every sentence adds useful context, making it compact and effective.

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 simple read-only tool with one optional parameter and no output schema, the description adequately covers what the tool returns (per-vehicle prices, currencies, vehicle tier details) and the parameter behavior. It is complete for the tool's complexity.

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 schema description for routeSlug already fully explains the parameter (optional, from list_routes, omit for all routes). The tool description repeats this information without adding new semantic details, so it meets the baseline for high schema coverage.

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 gets fixed per-vehicle prices for a route, or all routes if no routeSlug is given. It uses a specific verb and resource, and explicitly contrasts with surge/metered pricing, distinguishing it from sibling tools like estimate_price.

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 implies when to use this tool: when fixed prices are needed, and explicitly mentions that prices are fixed with no surge or metered fares, which distinguishes from estimate_price. It also explains behavior when routeSlug is omitted. However, it does not explicitly name alternative tools or state when not to use it.

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 annotations declare readOnlyHint=true and openWorldHint=false, so the read-only nature is already covered. The description adds the specific data categories returned but does not disclose additional behavioral traits such as rate limits, auth requirements, or response formatting. Given the annotation coverage, this is acceptable but not rich.

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, well-structured sentence that lists all relevant content categories. It is concise with no redundancy; each item adds meaningful 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?

For a no-parameter read-only tool, the description is quite complete, enumerating all returned data categories including contact details and booking instructions. However, without an output schema, it does not specify the response structure, which leaves slight ambiguity about the exact format.

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 is empty with no parameters. The baseline for a 0-parameter tool is 4, and the description does not need to explain any parameter semantics because there are none.

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' with a clear resource 'business info' and enumerates exact contents: service area, accepted payment methods, supported languages, minimum booking lead time, contact details, and how to book including the booking URL template. This clearly distinguishes it from sibling tools like get_pricing and list_routes.

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 implies the tool should be used to retrieve general business information, which is clearly indicated by the listed contents. It does not explicitly mention alternatives or when-not-to-use scenarios, but the scope is evident from the detailed list. No exclusions are noted.

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, and the description adds that only 'active' routes are listed and enumerates the returned fields. This goes beyond the annotation without contradiction, though it doesn't discuss pagination or sorting.

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 sentences with zero filler. The first sentence front-loads the action and the output fields; the second adds a clear usage directive. Every phrase 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 parameterless list tool with no output schema, the description fully conveys the scope ('active' routes) and the output fields, making it complete for an agent to invoke 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?

The tool has zero parameters and the schema is empty. The description correctly implies no input is needed, so the baseline for a 0-param tool (4) applies.

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 specific verb 'List' with resource 'airport-transfer routes' and enumerates the returned attributes (slug, endpoints, distance, etc.), clearly distinguishing this from booking/pricing siblings.

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 instruction 'Use this first to discover what routes exist' provides explicit when-to-use context. It does not name alternatives or state when not to use, but the guidance is clear enough to sequence the tool before estimate_price or get_pricing.

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