Airport Pickups London

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: per-car-type fixed pricing, inclusion of the Eurotunnel crossing, a no-discount pricing rule, and the fallback return (list of available EU destinations) when a city is unconfigured.

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-loaded with the core purpose, then routing rule, then return/pricing behavior and the fallback path. Dense and mostly waste-free, though the capitalized emphasis and multiple clauses make it longer than strictly necessary.

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 carries the burden of describing returns and does so (per-car-type prices, fixed per vehicle, Eurotunnel included, final prices). It also covers the failure mode and the correct customer-facing response, leaving no obvious gap for correct 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 schema already documents car_type, hub_code and destination with their constraints and examples. The description adds only the domain scope for destination (continental city); baseline 3 is appropriate since the schema does the heavy lifting.

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 (get prices) and resource (European/cross-Channel transfer from London/UK to a continental destination), with example cities. It explicitly distinguishes itself from the sibling london_airport_transfer_quote, so an agent can route correctly without opening either schema.

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 an explicit use condition ('whenever the destination is OUTSIDE the UK / on the European continent') and names the alternative tool to avoid by name. It even covers the edge case of an unconfigured city and what to tell the customer.

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

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

Beyond the annotations (readOnly/openWorld/non-destructive), it discloses substantial behavior: role-based visibility (customers/agents get availability-only, staff get full detail), the exact fields suppressed (driver name, vehicle, plate, position, distance, fleet size), an ETA rounded to 5 minutes, a 5-car cap, and the rule that driver details are released only after a booking is confirmed. This is exactly the kind of context structured fields cannot carry.

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-loaded with the core action and target formats, then the return/visibility rules; it is a dense paragraph rather than a bloated one, and each clause carries information. It runs slightly long, but no sentence is pure padding.

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 carries the return-value burden and does so fully: what the response contains (car type, seats, rounded ETA, per-car-type summary), what it omits, and how it differs by caller role. An agent has enough to call and interpret 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%, so 3 is the baseline, but the description adds real meaning the schema lacks: the enumerable set of airport codes, that min_pax enforces a vehicle size tier, that include_on_job is for staff seeking busy drivers, and a customer-facing result cap of 5 cars even though the schema's limit allows 25. That role/limit interaction is important context above 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 opens with a precise verb+resource ('Find the closest available drivers to a location using live fleet GPS') and scopes it to availability, which implicitly separates it from route/tracking siblings like track_driver and get_driver_route. It never names a sibling explicitly, so an agent gets clarity but not direct routing guidance.

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 lists the accepted target formats (airport code, postcode, lat+lng) and role-dependent behavior, which implies usage, but gives no explicit when-to-use/when-not or alternatives ('use this instead of X when...'). The agent must infer that this is the pre-booking availability lookup.

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 cover the safety profile (readOnly, non-destructive, openWorld), yet the description still adds real behavioral context beyond them: the trail is recorded only while the driver is on the job, is retained for 30 days, and access depends on whether the caller is internal staff or a partner/customer. Retention window and recording conditions are exactly the kind of operational detail annotations cannot express.

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, front-loaded with what the tool returns and immediately followed by when to use it and the access constraint. The parenthetical gloss on 'breadcrumb trail' earns its place by disambiguating jargon; nothing is padding.

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 carries the return shape itself (the driven path plus a distance/duration summary) and adds retention and authorization constraints. For a two-parameter read tool with annotations, 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 both parameters are already documented, and the description's restatement of the email-vs-numeric-ID rule largely mirrors the schema text. It confirms rather than extends parameter meaning, which is the baseline-3 case when the schema does the heavy lifting.

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 with unusual precision: the driver's recorded GPS route as a breadcrumb trail for a booking's trip, plus a distance/duration summary. The word 'recorded' implicitly separates it from the live sibling track_driver, but no sibling is named explicitly, so it stops short of the top score.

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?

Gives two concrete use cases ('route playback', 'verify a driver attended'), which is clear context for when to reach for it. It offers no when-not guidance and does not name track_driver as the alternative for live position, so an agent must infer the boundary itself.

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, destructiveHint=false, and openWorldHint=false, so safety and lookup scope are covered structurally. The description adds that this surfaces FAQ/policy content, but says nothing about whether the answer is a static knowledge base versus synthesized, nor about truncation or confidence.

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?

Purpose is front-loaded in the first clause and the usage note follows. The long topic list is helpful for retrieval cueing but borders on padding, with "and any other frequently asked questions" adding no 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 one-parameter read-only lookup with no output schema, the description supplies enough for an agent to call it correctly. Return format is unmentioned but not strictly required given the simple contract.

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?

Single parameter with 100% schema description coverage, so the schema already documents the 'question' field and its examples. The topic enumeration in the description loosely mirrors those examples, adding little beyond what the schema 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?

Specific verb (get information) plus a concrete, enumerated resource (Airport Pickups London services, policies, vehicles, pricing, cancellation, etc.). The topic list makes it unmistakably distinct from the booking-management siblings like amend_booking and cancel_booking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use this when customers ask about how the service works" gives a clear triggering context. It does not explicitly name alternatives or state when NOT to use it, but the sibling set makes the FAQ role obvious by contrast.

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 cover the safety profile (readOnlyHint, destructiveHint false, openWorldHint). The description adds a real behavioral limit not in the annotations: it only works with future scheduled flights, which tells the agent when validation will fail. Return payload contents are also previewed.

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 front-loaded sentences: the first delivers purpose and return fields, the second delivers usage context and the scheduling constraint. No redundant or filler text.

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 usefully enumerates the returned fields (airline name, airport, terminal, arrival time), and the date parameter is fully specified in the schema. Only minor gaps remain, such as error behavior for invalid or past flight numbers.

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 both flight_number and date fully documented including format examples, so the schema carries the parameter semantics. The description adds no format or constraint detail beyond what the schema provides; baseline 3 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 states a specific verb and resource (validate a flight number) and enumerates the resulting data (airline, arrival airport, terminal, arrival time). This is unmistakably distinct from the surrounding booking-management siblings without needing to name them.

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 a concrete use case (verify a customer's flight number before booking, auto-detect the terminal) and a scope constraint (works with future scheduled flights). It does not name an alternative tool, but no sibling overlaps this function, so the guidance is effectively complete.

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