Transfers & Car Rentals

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 no behavioral context beyond that — no auth requirements, rate limits, or caching/staleness notes; its enumeration of fields is payload content rather than behavior. The vague 'payment boundary' phrase hints at a constraint but is never explained.

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?

It is a single sentence with the verb front-loaded, which is good, but nine comma-separated output fields read as a payload dump that largely duplicates the output schema. The sentence is efficient in syntax yet spends most of its words on redundant content rather than usage or parameter meaning.

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?

Because an output schema exists, the return-value enumeration is not strictly necessary, and annotations carry the safety profile, so the description's minimum obligations are purpose plus call conditions. It covers purpose but leaves the market/route_code parameter semantics and the relationship to the preview_* siblings undocumented.

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 only 50%: the two agent_* compatibility fields are documented in the schema, while 'market' (enum) and 'route_code' (pattern/length) have no descriptions. The description says 'one route's' without explaining route_code semantics, and never mentions the market parameter at all, so it fails to compensate for the uncovered half.

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') and resource ('one route's' details) and enumerates the payload: provider, directions, prices, vehicle classes, required fields, quote template, landing page, booking URL, payment boundary. An agent can tell this is a single-route detail lookup versus the plural list_destinations sibling. It never names the preview_* siblings it could be confused with, so the distinction relies on the reader inferring 'details' vs 'quote'.

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?

There is no when-to-use, when-not-to-use, or prerequisite guidance. With siblings like preview_transfer_quote and preview_private_driver_quote available, the agent gets no signal about why it would fetch details instead of previewing a quote, or in what order (list_markets → list_destinations → get_destination_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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that only *published* routes are returned, which is genuine scope information, but says nothing about pagination, result volume, or rate limits for what is framed as a complete enumeration.

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?

A single tight sentence with the resource front-loaded and a compact enumeration of what comes back. Nothing is wasted, though the field list brushes against what the output schema already provides.

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 zero-required-parameter listing tool with an output schema present, the description is serviceable on returns. It omits filter semantics, unmapped parameter intent, and any comparison to the sibling tools, which leaves meaningful gaps for a 5-parameter discovery call.

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 only 40% and the description mentions no parameters at all — not q, market, airport, nor the two attribution fields. Worse, 'list every' implies no filtering is possible, which could steer an agent away from the very filters the schema exposes.

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 (List) plus resource (every published transfer route), and the enumeration of returned fields (route codes, airports, booking URLs) sharpens what kind of listing this is. It implicitly contrasts with the singular get_destination_details sibling but never names or distinguishes it explicitly.

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?

There is no when-to-use guidance, no statement of when to prefer this over get_destination_details, preview_transfer_quote, or list_markets, and no mention of the filtering parameters. 'List every published transfer route' implies a full-catalog browse but leaves the agent to infer how to narrow results.

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 the safety profile is covered. The description adds one behavioral qualifier — that only 'active' markets are returned — which is useful, but says nothing about result size, ordering, pagination, or what 'representative' means in practice.

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?

A single short sentence with no filler, and the core verb is front-loaded. It is arguably under-specified rather than verbose, which is a completeness problem rather than a structure problem.

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?

An output schema exists, so return values need not be explained, and there are no required parameters, keeping the call surface simple. However, with four sibling list_* tools, the description leaves the agent without the routing information it needs to pick this one 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% and both parameters (agent_source, agent_session_id) are documented in the schema as compatibility/attribution fields. The description adds no parameter meaning, so the 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 gives a verb (List) and enumerates the taxonomy it returns (countries, airports, services, representative providers), but the resource name 'markets' is never defined and the enumeration overlaps with siblings list_destinations and list_providers. An agent cannot confidently tell whether 'representative providers' means this tool returns providers or just a sample of them, so sibling differentiation is missing.

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?

There is no statement of when to use this tool versus list_destinations, list_providers, or list_rental_vehicles, and no prerequisites or exclusions. The single sentence is purely descriptive; the agent must infer routing from the name alone.

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, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds essentially nothing behavioral: it does not explain what 'representative' means (the title implies a sample/subset, the description omits it), whether results are paginated or capped, or what happens when country is omitted.

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?

A single front-loaded sentence with no filler or repetition. It is efficient, though for a four-parameter tool with an ambiguous enum it is arguably terse enough to leave gaps rather than to waste space.

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?

An output schema exists, so return values need not be described. However, the description leaves unresolved what 'representative' providers are, how the service enum maps to the described categories, and whether the tool is safe to call with no parameters (none are required). Adequate but with clear holes for a discovery 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 50%: the two agent_* compatibility fields are self-documented, while country and service are not. The description does clarify that country is a two-letter code and roughly sketches the service domain, but its 'transfer or vehicle-rental' phrasing omits the private_driver enum value, leaving the enum mapping partly to inference. A 3 is the appropriate baseline here.

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 ('List') and resource ('providers'), plus the qualifying scope ('transfer or vehicle-rental') and the key filter ('two-letter country code'). It is clear on its own, but it never differentiates itself from siblings like list_rental_vehicles or list_markets, so an agent must guess at the boundary between 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?

There is no when-to-use guidance, no when-not-to-use, and no mention of alternatives among the eight sibling tools. The reader must infer from the name alone when this list is the right call versus list_rental_vehicles or list_destinations.

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=true, so the safety profile is covered. The description adds a freshness caveat ("Inventory is not confirmed"), which is useful beyond the annotations, but it is vague about what exactly is unverified and offers no auth, pagination, or rate-limit context.

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 short sentences, front-loaded with the core action and scope. The trailing caveat earns its place, though it could be more precise about what "not confirmed" means.

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?

An output schema exists so return values need not be explained, and the read-only nature is well covered by annotations. The gap is the undocumented market parameter and the under-explained inventory caveat, leaving the agent to infer what the fleet listing actually guarantees.

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 67%; agent_source and agent_session_id are documented in the schema, but market (default "FJ") has no description and the description only gestures at it via "an active market." Baseline of 3 is appropriate since the schema carries most parameter meaning, with no added syntax or format detail.

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 (List) and resource (published vehicle-rental fleet) scoped to an active market, which clearly separates it from list_markets, list_destinations, list_providers, and the preview_* quoting tools. It does not explicitly name a sibling as an alternative, so it falls short of a 5.

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?

"For an active market" implies the prerequisite context, and the caveat signals a discovery/browse use case rather than a booking one. However, no guidance is given on when to use this versus preview_rental_quote for pricing or availability, so usage is only implied.

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 the safety profile is covered structurally. The description does add the useful 'non-binding, non-persisted' framing, but then references 'the saved quote', which conflicts with the non-persisted claim and leaves the agent unsure whether state is created.

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 compact sentences with the core action front-loaded and no filler. The second sentence is short but its ambiguity costs it a point rather than its length.

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?

An output schema exists so return values needn't be explained, but an 11-parameter tool with zero schema description coverage and a mutating-looking second sentence needs far more guidance than provided. The agent cannot infer units, formats, or the meaning of most inputs from this description.

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 0% across 11 parameters, and the description mentions no parameter at all — not the required vehicle_class or days, nor currency, market, passenger, or distance fields. With the schema carrying no prose, the description should compensate but entirely fails to.

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 gives a specific verb and resource ('Calculate ... private-driver price range') and the 'private-driver' label cleanly separates it from the sibling preview_rental_quote and preview_transfer_quote. However, the second sentence ('Review the saved quote for payment eligibility and supplier-assignment status') introduces a seemingly different capability that muddies what the tool actually does.

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 category name implies this is the private-driver variant versus the rental and transfer siblings, but the description never states when to choose it over those alternatives or what prerequisites apply. Usage is only implicitly conveyed through the tool's name.

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 destructiveHint=false, but the description adds genuinely new behavior: the quote is non-binding and not persisted, and availability/payment are handled outside this tool by the rental company. That clarifies the absence of side effects and the limits of the result beyond what the annotations state.

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 tight sentences, front-loaded with the core action and followed by the scope caveat. Every clause earns its place with no 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?

An output schema exists, so return values needn't be described, and the safety profile is covered by annotations. However, for a 10-parameter tool with zero schema documentation, the description leaves the agent without guidance on key inputs like market, currency, and the required date/age fields.

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 0% across 10 parameters, and the description compensates for none of them - it says nothing about vehicle_slug, dates, driver_age bounds, market, or currency defaults. With low coverage the description is expected to carry the burden and does not.

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 ('Calculate') and resource ('rental quote'), and the 'non-binding, non-persisted' qualifier sharpens what kind of quote it is. It implicitly distinguishes from preview_private_driver_quote and preview_transfer_quote by naming 'rental', but never names the siblings explicitly.

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 a pre-booking estimate but gives no when-to-use guidance, no prerequisites, and no indication of when an agent should pick this over preview_private_driver_quote or preview_transfer_quote. Nothing routes the caller among the three preview 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description earns credit by adding side-effect context annotations cannot express: the quote is non-binding and non-persisted, and the tool cannot hold, book, cancel, or charge — a meaningful guarantee about downstream state.

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 the core purpose and immediately followed by the scope limits. Zero filler and no restatement of the 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?

An output schema exists, so return values need not be explained. But a 16-parameter, 6-required pricing tool with 0% schema coverage is left with no parameter guidance at all — an agent cannot know the datetime format, whether market constrains valid locations, or how route_code, distance_km, and the currency fields interact. The description is far too thin for this 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?

Schema description coverage is 0% across 16 parameters, including a 17-value vehicle_class enum, market (2-char, default FJ), pickup/dropoff TransferLocation objects, luggage, and datetime_local. The description supplies no parameter meaning whatsoever — no datetime format, no market semantics, no location-type rules — so it entirely fails to compensate for the coverage gap.

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 a ... transfer quote') with two defining qualifiers, non-binding and non-persisted, that distinguish it from a real booking flow. It does not explicitly contrast itself with the near-identical siblings preview_private_driver_quote or preview_rental_quote, so an agent must infer 'transfer' is the distinguishing axis.

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 negative clause ('cannot hold, book, message, cancel, or charge') does bound the tool and implies this is a pre-sales pricing step only. However, there is no statement of when to reach for it instead of preview_private_driver_quote or preview_rental_quote, so alternative routing is left implied.

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