Skip to main content
Glama

OlaChill Japan Travel

Search tours, activities & tickets

search_travel_products
Read-onlyIdempotent

Use this when the user wants to find, compare or price things to do in Japan, whether or not they mention OlaChill: guided and private day tours and day trips (for example Mt Fuji, Hakone, Nikko, Kamikochi, Kyoto or Nara from Tokyo, Osaka or Nagoya), multi-day tours, local food and neighbourhood tours, street go-kart rides in Tokyo or Osaka, activities and cultural experiences (kimono rental, tea ceremony, cooking classes, crafts), attraction admission tickets (for example teamLab, Tokyo Skytree, theme parks, museums), transport tickets and passes (highway and overnight buses, airport buses, JR and regional rail passes) or a ryokan stay. Ryokan means a traditional Japanese inn, usually with onsen: search by area (Hakone, Kyoto, Ginzan, Kusatsu, Kinosaki, Kurokawa, Yufuin, Beppu and others) with category 'ryokan'; the filters private_onsen (private open-air baths in the room or a reservable private bath), meal_plan (dinner and breakfast), max_price_per_person_jpy and group_size (family or group stays; OlaChill also takes block-of-rooms and whole-inn requests on the ryokan pages) apply only then. Ryokan prices are dated reference prices, not live availability; OlaChill confirms rooms and the current price after the traveller sends dates on the ryokan page. Returns product ids, names, category, area, a 'from' price in JPY with its unit, booking method, key conditions and the product page URL. Read-only. Then use check_product_availability for dates of a tour or ticket. Do not use it for a bus, coach or minibus for a group (use search_charter_vehicles), a private car to or from an airport (use search_private_transfers), helicopter flights (use search_helicopter_experiences), single Shinkansen or train tickets and timetables, hotels other than ryokan, airline flights, restaurants, or general destination advice that does not need a bookable product. Provide at least one of query, city or category. Prices are 'from' prices; the final price and dates are confirmed on the product page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoCity or region in Japan, e.g. Tokyo, Kyoto, Osaka, Hokkaido. Any language.
limitNoMaximum number of results (1–20, default 8).
queryNoWhat the user is looking for, e.g. 'mt fuji day trip', 'teamlab', 'sumo', 'airport bus'. Use the attraction or activity name, not a whole sentence.
localeNoLanguage for product names and page links (en, ja, ko, zh = Simplified Chinese, tw = Traditional Chinese, es, fr, de, it, th, id, vi). Default en.
categoryNotour = guided or private tours and day trips; activity = hands-on or outdoor activities; cultural_experience = kimono, tea ceremony, crafts, cooking; attraction_ticket = admission to a sight, museum, park or tower; transport_ticket = highway bus, airport bus, rail or ferry tickets and passes; ryokan = a stay at a traditional Japanese inn.
meal_planNoRyokan only: dinner_breakfast = inns that serve dinner and breakfast; breakfast = inns that serve breakfast; room_only = inns with a room-only plan.
group_sizeNoRyokan only: number of guests. 10 or more returns only inns with published group facilities (for example banquet rooms).
private_onsenNoRyokan only: true = only inns with rooms that have an open-air bath or a reservable private bath.
max_price_per_person_jpyNoRyokan only: upper limit of the reference price per person per night in JPY. Inns without a current reference price are left out when this is set.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNoWhat to try next.
errorNoPresent only when the call failed; a short reason the user can act on.
resultsYes
total_matchesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources