OlaChill Japan Travel

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

Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description adds real behavioral context: nothing is reserved or held, an open date can still sell out before checkout, unsupported product categories return 'unsupported' with a page link, and there is a 31-day-per-call cap. These are non-obvious operational traits not derivable from 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?

Front-loaded with the user-intent trigger and example phrasings, then prerequisites, exclusions, and limits. Dense but every clause carries information; it could be split for readability but there is little waste.

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 an output schema exists, the description needn't detail return structure, yet it usefully summarizes the tri-state result (open/closed/unknown) and the unsupported case. Combined with prerequisites, limits, and exclusions, an agent has everything needed to call it correctly in one shot.

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 beyond the schema by explaining the provenance of product_id (must come from search_travel_products) and which product_id prefixes are supported versus returning 'unsupported'. It does not restate the locale enum or date format, which the schema already handles.

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+resource (check whether a given OlaChill tour/ticket is bookable on certain dates) and names the exact upstream tool that supplies the required product_id (search_travel_products). An agent can distinguish it from siblings like search_travel_products or get_booking_status without opening any 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?

Gives explicit when-to-use triggers with example user phrasings, an explicit prerequisite ('call search_travel_products first if you do not'), and explicit exclusions (not for booking, charter coaches, transfers, helicopter flights, or without a product_id). Nothing is left to inference.

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/idempotentHint/destructiveHint=false, so safety is covered. The description adds real behavior beyond that: the prerequisite that both reference and email are mandatory, the instruction never to guess either, and that it points the user to a manage-booking page for changes.

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 dense sentences that are front-loaded with the use case, then returns, then exclusions and prerequisites. No filler; every clause carries routing or requirement 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 3-parameter read-only lookup with full schema coverage and an output schema (so return values need not be detailed), the description covers purpose, prerequisites, exclusions, and routing to the manage-booking alternative. Nothing an agent needs is missing.

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 baseline is 3; the description goes further by giving concrete booking_id formats (TOKY-1018-0427, BUS-FR-1018-0427) and stressing that both reference and email must be present.

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 action (look up the status of) and a precise resource (an existing OlaChill booking, order or quotation request), and its read-only lookup nature clearly separates it from the search_* and request_* 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?

It gives explicit when-to-use (user asks about an existing booking and supplies reference plus email), explicit when-not-to-use (not for finding new products, not for changing/cancelling), and names the correct alternative for changes (the manage-booking page it returns).

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 only declare readOnly/idempotent/non-destructive; the description goes further by disclosing that every result is an estimate OlaChill confirms after checking vehicle availability, that Japan returns a fixed 10-hour package price with vehicle/day counts, overtime rate and inclusion/exclusion breakdown, and that Europe/Schengen returns a rate-table price range. That is substantive behavioral context beyond the 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?

Front-loaded with the trigger sentence and organized as trigger → workflow position → region-dependent output → caveat → exclusions, with no filler. The parenthetical example list is dense and slightly run-on, which mildly hurts scanability.

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 12-parameter, dual-region pricing tool it covers everything an agent needs: required trip facts, workflow ordering, region-conditional behavior and output shape, the estimate caveat, and negative routing to three sibling tools. With an output schema present, it correctly avoids re-specifying the return payload.

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 baseline is 3, but the description adds usable semantics: a worked example ('45-seat bus Tokyo to Hakone on 20 March for 40 people'), the grouping of pickup/destination/dates/group size as the core inputs, and the region split that governs how country vs. region must be supplied. It stops short of explaining optional params like large_bags, pickup_hour or trip_type defaults.

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?

Names a specific verb+resource (estimate a charter coach price) and immediately bounds it by vehicle classes (bus, coach, minibus, van with driver) and required trip facts. It explicitly distinguishes itself from search_charter_vehicles (which it follows), request_charter_quote (the submission step), and search_private_transfers (1–6 airport runs), so an agent can route correctly without opening schemas.

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 explicit when-to-use (user wants a price for a specific charter trip), positions it as 'step 2 of the charter workflow, after or instead of search_charter_vehicles', and states three when-not cases with the alternative tool named for each. Nothing is left to inference.

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, idempotentHint and destructiveHint=false, and the description repeats 'Read-only' redundantly. It does add useful behavioral context beyond annotations: the fallback-only routing contract, the boundary topics OlaChill does not handle, and the return contents (service description, fit, page URL, booking and group-transport contact addresses).

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-loads the core use case in the first clause, then conditions and exclusions. The long enumerations of covered services and sibling-tool mappings are dense but each item serves routing, though the topic-to-sibling list could be tightened.

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 an output schema present, the return shape description is a bonus rather than a requirement, and the description fully covers when to invoke, when not to, and how to handle the boundary topics where OlaChill has nothing to offer. Nothing an agent needs to call this correctly is missing.

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?

Only one optional parameter (locale) with 100% schema description coverage, including the enum values and defaults, so the schema carries the full burden. The description never mentions locale or how it affects output, adding no meaning beyond the schema; baseline 3 applies for high 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?

States a specific verb+resource ('list OlaChill service areas') and frames it precisely as the fallback for services not covered by dedicated search tools. It enumerates the concrete domains it covers (private tours, medical travel, VIP immigration, self-drive rental, etc.), so an agent can match a novel user request to this tool without opening any 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?

Gives explicit when-to-use (fallback for uncovered Japan travel services or general 'what does OlaChill offer'), explicit when-not (do not substitute for dedicated tools) with a one-to-one mapping of topic to sibling tool, and an explicit do-not-call list (hotels other than ryokan, flights, weather, restaurants, visas) with instruction to answer without OlaChill 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description's 'Read-only' largely repeats it. It still adds real behavioral context the annotations cannot: the ranking is restricted to one catalogue, results carry explicit match reasons and considerations, a published 'from' price and product URL, and prices/availability may change so the product page is authoritative.

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 trigger condition, and every sentence carries routing, exclusion, or return-value information; little is filler. It is a dense single paragraph rather than a structured block, and the 'Read-only' clause duplicates the annotations, but the length is justified by the breadth of the exclusion list.

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 9-parameter, output-schema-backed recommendation tool with rich annotations, the description covers everything the agent needs: trigger, alternative, hard exclusions, what the results contain, and the staleness caveat on prices. Return-value detail is correctly left to the output schema, and no prerequisite information is missing.

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 nine parameters including enums, limits and the ryokan-only semantics (meal_plan, group_size, private_onsen). The description only gestures at the same fields ('area, interests, budget, private onsen or meal plan') without adding format or behavioural detail beyond the schema, 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?

States a specific verb and resource ('recommend... bookable Japan tours, activities, cultural experiences, tickets, ryokan') and immediately narrows scope: 'ranks only OlaChill catalogue items against the supplied criteria.' It also names the sibling it is not (search_travel_products), so an agent can distinguish the two 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?

Explicit trigger phrasing ('recommendations, suggestions, a shortlist, what should we do'), an explicit alternative with its selecting condition ('Use search_travel_products instead when the user names a specific product... exact inventory lookup'), and an explicit exclusion list (helicopter flights, transfers, hotels other than ryokan, restaurants, weather, visas). Nothing is left to inference.

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?

Goes well beyond the annotations: discloses that a copy is emailed to the traveller, that for Japan vetted operators bid without seeing contact details, that it creates a request record, that it does not book/reserve/charge, and that a repeat Japan request within 45 minutes returns the existing reference. The write/side-effect profile is consistent with readOnlyHint=false, destructiveHint=false and openWorldHint=true, and the 45-minute dedup note usefully qualifies the idempotentHint=false hint rather than contradicting it.

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 critical precondition is front-loaded and every clause carries information, but the body is a single dense run-on paragraph mixing preconditions, side effects and the Japan dedup rule. Length is defensible for a 19-parameter confirmation-gated mutation, though tighter sentence breaks would read better.

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 no explanation, and the description covers what the schema cannot: intent gating, sequencing after get_charter_quote, side effects, contact-data handling, and the confirmation requirement. Nothing an agent needs to invoke this safely is missing.

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 baseline is 3, but the description adds real parameter-level meaning: it groups the mandatory collection (region plus country for Europe, pickup, destination, date, passengers, name and email, phone for Japan) into a checklist and adds guidance absent from the schema ('never guess or invent contact details', 'set user_confirmed to true only after the user agreed to send this exact request'). It does not touch optional fields such as notes, locale or vehicle_type.

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 precise verb and resource ('sends the request to OlaChill's charter desk', 'creates a request record and returns its reference and status') and explicitly separates itself from the estimate step ('after you have shown an estimate from get_charter_quote'). An agent can distinguish it from get_charter_quote and the search_* siblings without opening any 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?

Gives an explicit invocation gate ('Use this only when the user explicitly asks OlaChill to check availability and send a quotation'), explicit exclusions ('Do not call it while the user is still comparing or only asked for a price'), and names the preceding alternative get_charter_quote. The sequencing precondition and the user_confirmed gate leave nothing to inference.

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, idempotentHint, and openWorldHint=false, and the description corroborates with 'Read-only'. Beyond that it discloses the shape of the response (seats, comfortable passenger count, luggage space, fit, vehicles needed, Japan 10-hour 'from' price) and positions itself as step 1 of a multi-step workflow that must not skip ahead. It does not discuss pagination, latency, or pricing caveats.

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 long but front-loaded with the trigger condition, then workflow context, then exclusions, so an agent can stop reading early. The example list in the first sentence is somewhat enumerative and could be trimmed, but every sentence carries routing or workflow 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?

With an output schema present and full schema coverage, the description does not need to re-document fields, and it correctly focuses on routing, workflow position, and exclusions. Nothing an agent needs in order to select and invoke this tool correctly is missing.

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 the enums are self-describing, so the schema already carries parameter semantics. The description only indirectly touches parameters, mentioning group size, luggage, and Japan/Europe scope; it adds no format or constraint detail beyond what the schema states. 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?

States a specific verb and resource ('matches the group to vehicle sizes') and names the exact vehicle types covered (bus, coach, minibus, large van with driver). It explicitly distinguishes itself from siblings search_travel_products, get_charter_quote, and search_private_transfers.

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 explicit when-to-use triggers (school trip, company outing, MICE, wedding shuttle, airport group transfer) plus a where-it-applies scope (Japan or supported Schengen countries). It also states the three-step charter workflow and three explicit 'do not use it for' exclusions, each paired with the correct alternative.

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, idempotentHint and destructiveHint=false, and the description's 'Read-only' restates that, which is redundant. It does add value beyond the structured fields by disclosing the pricing model (day-hire per car per prefecture vs hourly reference rate for Tokyo), the confirmed-vs-estimate distinction, and that booking/payment behavior is returned.

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 capability and the exclusion routing, both high-value. It runs long and the long enumeration of vehicle models (Alphard, LM, LS, LX, ES, Crown, V-Class) is illustrative padding, but every other clause 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?

With an output schema present the description needn't detail returns, yet it still summarizes them; annotations cover the safety profile; and all 8 parameters are fully documented in-schema. An agent has everything needed to select and call this 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 the baseline is 3. The description adds meaning on top by linking hire_type/prefecture to the pricing outcome (day-hire by prefecture, hourly Tokyo reference rate) and noting the waiting-driver model, which helps an agent pick parameters rather than merely echo the schema text.

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+resource (find a private car with driver) with scope (by the day or by the hour in Japan) and concrete examples of vehicle classes and use cases. It explicitly distinguishes itself from search_private_transfers, search_charter_vehicles, list_olachill_services and taxis, so an agent can route correctly without opening any 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?

Explicit when-to-use (day or hourly chauffeured car for sightseeing, business, shopping, day trip with waiting driver) and when-not-to-use with named alternatives for each exclusion (one-way airport transfers, >6 passengers, buses/coaches, self-drive, taxis). Nothing is left to inference.

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, idempotentHint=true, destructiveHint=false, so the safety profile is covered and the description's 'Read-only' line is largely redundant. It does add real behavioral context beyond the annotations: what each result contains (data allowance, validity, tax-included JPY price, order page) and the linkage rule that trips over 90 days return monthly plans. No auth, rate-limit, or pagination detail, hence not a 5.

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 triggering condition and packed into essentially two sentences with no filler; every clause maps to a real selection axis or exclusion. It is dense and clause-heavy rather than crisp, which keeps it just short of a 5.

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 enumerated, and the description still flags the key fields and currency. With all parameters enumerated, an explicit exclusion list, and an off-ramp for eSIM compatibility, an agent has everything needed to call this correctly against its siblings.

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 all three enums are documented in-schema, so the baseline is 3. The description restates the same semantics in user-intent language ('which travel eSIM covers a trip of a given length', 'unlimited versus 3GB per day', 'monthly eSIM for living longer than 90 days'), but adds no mapping detail beyond what the schema already says — including the 90-day travel/monthly default, which the schema states verbatim.

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 names a specific verb and resource (finds travel/monthly eSIM plans for Japan) and enumerates the exact decision axes it resolves: unlimited vs 3GB/day, trip length, monthly vs travel, cost. It also carves itself away from adjacent siblings — physical SIMs, pocket Wi-Fi, roaming in other countries, phone repair — so an agent can separate it from search_travel_products without opening a 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?

Explicit when-to-use ('user wants mobile data in Japan on an eSIM') plus explicit when-not-to-use ('Do not use it for physical SIM cards, pocket Wi-Fi rental, roaming in other countries, or phone repair'), and it routes the out-of-scope eSIM-compatibility question to the compatibility page in the result. That is the full when/when-not/alternative pattern.

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, idempotentHint, destructiveHint false and openWorldHint false, so safety is covered; the description adds the payoff detail of what each result carries (area, per-golfer price where published, add-ons, club cancellation terms, online-payable vs on-request). It does not add pagination or ranking behavior, but the transparency bar is lowered by the rich 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?

Front-loaded with the use case, then the return shape, then exclusions in a compact block. The long opening sentence is dense but each clause earns its place; 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?

Covers purpose, exclusions, and result contents, and an output schema exists so return-value structure need not be restated. An agent has everything needed to select and call this 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 description coverage is 100% and every parameter has a detailed description, so the schema carries the load. The description reinforces intent-to-parameter mapping (round vs one-day vs multi-day trip, named regions) but adds no syntax or constraint detail 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?

States a specific verb and resource (search golf packages/rounds and trips) and enumerates the concrete scope: a single round, a one-day trip with hotel pickup, or a multi-day package, in named regions. It is easily distinguishable from siblings like search_chauffeur_services and search_travel_products.

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 gives when to use (user wants golf arranged with round and transport) and when not to use, naming the alternative tool for each excluded case (chauffeur without golf, sightseeing products). No inference required.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. Beyond that, the description discloses the result shape that matters for decision-making — per-person vs whole-aircraft seat selling, JPY 'from' pricing, departure heliport, and whether OlaChill confirms the slot with the operator — which is genuine behavioral context rather than restatement.

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 front-loaded with the trigger sentence, and the exclusion sentence is last, which is the right ordering for an agent skimming. The middle enumeration of use cases is long and somewhat repetitive, and the return-field list partly duplicates the output schema, but nothing is off-topic.

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 read-only discovery tool with a full output schema and 100% parameter coverage, the description supplies the decision-relevant context: trigger, scope, exclusions, and the differentiating result fields. An agent has everything needed to choose this tool over its twelve siblings and 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 the schema already documents all six parameters, and the enum semantics are spelled out in the schema itself. The description does help map natural-language intent onto enum values (Mt Fuji/Yokohama/Osaka/Kyoto → area, night-view → time_of_day, charter/heli-taxi → service_type), but that is inferable from the enums. 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 states a specific verb+resource (search helicopter experiences/flights in Japan) and then enumerates concrete subtypes — sightseeing loops, night-view, charter, heli-taxi transfer — which pins down scope precisely. It explicitly distinguishes itself from search_travel_products for non-helicopter tours and from airline/ground transport, so an agent can separate it from every sibling without opening a 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?

It gives an explicit trigger ('use this when the user wants a helicopter experience in Japan, whether or not they mention OlaChill'), names the fallback sibling for non-helicopter tours, and lists clear exclusions (airline flights, ground transport). Both the when and the when-not conditions are stated rather than 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 read-only, idempotent, non-destructive behavior, but the description adds useful behavioral detail beyond them: it returns fixed one-way prices per vehicle, vehicle and capacity details, booking conditions, and the booking page. This materially helps the agent understand what invoking the tool produces.

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 usage conditions, followed by return details and exclusions, so its structure is strong. It is long and dense, and the standalone 'Read-only.' sentence is redundant with annotations, but nearly all content serves routing or usage decisions.

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 output schema, annotations, and five optional parameters, the description is complete enough for correct invocation. It covers scope, exclusions, alternatives, capacity constraints, examples, and expected return information without needing to duplicate the schema.

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 schema already documents each parameter. The description adds valuable meaning beyond it by specifying that this tool is for 1–6 travellers and large suitcases, and by giving examples of airports and destinations that map to the airport and destination 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 states a specific verb and resource: finding private airport transfers. It names concrete routes, airports, destinations, and the exact return content, so an agent can distinguish it from charter, shared bus, and taxi tools without opening the 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?

It gives explicit when-to-use conditions, including traveller count, route types, and whether the user mentions OlaChill. It also gives clear when-not-to-use guidance with named alternatives: search_charter_vehicles for buses and larger groups, and search_travel_products for shared airport buses and limousine bus tickets.

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, idempotent, non-destructive), so the bar is lower, yet the description still adds real substance: ryokan prices are dated reference prices not live availability, confirmation happens after the traveller sends dates, and listed prices are 'from' prices with final price confirmed on the product page. The only redundancy is the bare 'Read-only' restatement of readOnlyHint.

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 usage trigger and the ryokan explanation before the exclusion list, and every clause carries routing or pricing information. It is a dense single block that is long for a search tool, but it is not padded with filler; the length is driven by the breadth of categories it must disambiguate.

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 nine parameters and no required fields, the description covers what the tool returns, the meaning of 'from' pricing, the ryokan-specific filter scope, the minimum input requirement, and the full boundary against every relevant sibling. An output schema exists and the description still orients the agent on result contents, so nothing needed to call it correctly is missing.

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 goes beyond the schema by grouping the ryokan-only filters (private_onsen, meal_plan, max_price_per_person_jpy, group_size) and stating they 'apply only then', tying them to the category='ryokan' path, and by adding the cross-parameter constraint that at least one of query/city/category must be supplied.

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 set (find, compare, price) and enumerates the exact resource space — tours, day trips, activities, cultural experiences, attraction tickets, transport tickets, ryokan stays — with concrete examples (Mt Fuji, teamLab, JR passes). An agent can immediately tell whether a user request falls inside this tool versus any sibling.

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 names the follow-on tool for dates ('Then use check_product_availability') and gives an exhaustive when-not-to-use list routing each out-of-scope case to a named sibling (search_charter_vehicles for group buses, search_private_transfers for airport cars, search_helicopter_experiences for helicopters). It also states the minimum input requirement ('at least one of query, city or category').

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