OlaChill Japan Travel

Match a group to charter vehicles

search_charter_vehicles

Read-onlyIdempotent

Use this when a group needs its own bus, coach, minibus or large van with a driver, whether or not they mention OlaChill: for example charter bus or coach hire in Japan, a private bus with driver, a school trip, company outing or incentive trip, MICE or conference transport, a wedding shuttle, a tour group, an airport group transfer, or a large group with luggage, in Japan or in a supported Schengen country in Europe. This is step 1 of the charter workflow: it matches the group to vehicle sizes. Returns vehicle classes with seats, comfortable passenger count, luggage space, whether each fits the group, how many vehicles are needed and, for Japan, the 10-hour package 'from' price per vehicle. Read-only. Step 2 is get_charter_quote for a specific itinerary and date; step 3, request_charter_quote, only after the user explicitly asks to send a quotation request. Do not use it for scheduled public bus or train tickets (use search_travel_products), for the price of a specific trip (use get_charter_quote), or for 1–6 people going to or from an airport (use search_private_transfers).

Input Schema

TableJSON Schema

Name	Required	Description
`locale`	No	Language for product names and page links (en, ja, ko, zh = Simplified Chinese, tw = Traditional Chinese, es, fr, de, it, th, id, vi). Default en.
`region`	Yes	japan, or europe for Schengen countries.
`country`	No	Required when region is europe.
`large_bags`	No	Number of large suitcases (default one per traveller for airport trips, otherwise 0).
`passengers`	Yes	Number of travellers.

Output Schema

TableJSON Schema

Name	Required	Description
`hint`	No	What to try next.
`error`	No	Present only when the call failed; a short reason the user can act on.
`region`	Yes
`country`	No
`page_url`	No
`vehicles`	Yes
`next_step`	No
`vehicles_needed`	No	Number of the largest vehicle needed when one vehicle is not enough; 1 otherwise.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All OlaChill Japan Travel tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?