Vedar 如何以本地營運商資料規劃堪察加半島 7 日行程，並刻意保留一天空檔

A 7-Day Kamchatka Trip Plan That Leaves a Day Empty on Purpose

How our AI trip planner builds itineraries from real operator data and refuses to invent tours or prices

Ask any chatbot to "plan a week in Kamchatka" and you'll get a confident, nicely formatted itinerary. The trouble is where it comes from: old blog posts and travel articles. The tours may not run on your dates, the prices are years out of date, and nobody mentions that a bear-watching permit has to be booked two weeks in advance.

At Vedar we built a trip planner for Kamchatka that an AI assistant can call in the middle of a conversation, and it answers with live data from local operators. This post covers what it returns, the three design rules behind it, and how to connect it to your own assistant.

What the traveller sees

Someone tells their assistant (Claude, ChatGPT, Cursor, anything that can connect an external MCP server): "We're two people, 7 days in Kamchatka in July, volcanoes and bears." The assistant calls Vedar's make_trip_plan tool and gets back a day-by-day plan in a few seconds.

Here's the real response for a trip starting July 10, 2027 (translated from Russian, which is the platform's data language):

• Day 1. Arrive in the afternoon, check in, acclimatise, walk around town.
• Day 2. Bears, Avacha zone. Guide only: a permit for the South Kamchatka Federal Reserve is required, book 14 days ahead. Accredited guide only; keep at least 50 m from bears.
• Day 3. Trekking, Avacha zone.
• Day 4. Volcanoes, Avacha zone. Guide only: high risk (volcano ascent). Trekking boots, rain jacket and layers are mandatory.
• Day 5. Free day: town, souvenirs, fish market.
• Day 6. Not filled: we have no confirmed departure for this date, so we didn't make one up.
• Day 7. Pack in the morning, airport transfer, afternoon flight.

The plan also comes with a price estimate per person: 53,500–120,000 ₽ at "comfort" accommodation, with a breakdown:

• activities: 23,000–73,000 ₽ (a reference range for each activity type, explicitly not a tour price)
• accommodation: 28,000–42,000 ₽, estimated by zone and comfort level
• local transport: 2,500–5,000 ₽

For the group of two that's 107,000–240,000 ₽. Flights to Kamchatka aren't included, and the response says so.

Note how the response labels each number: which ones are estimates, which are reference ranges and which are real tour prices. The assistant passes that on to the traveller, so they know what's firm and what's a ballpark.

Rule 1: an honestly empty day beats a plausible fake one

Day 6 is empty on purpose. When there's no confirmed tour for a date, the planner says so instead of filling the gap with something that sounds right. The response states it plainly: "Filled 6 of 7 days: we have no confirmed departures for the rest. We don't invent the remaining days. Shift the dates or add interests and the plan will fill out."

The same rule applies to tours that don't fit. The Klyuchevskaya Sopka ascent takes 12 days. A naive generator would squeeze a "volcano day" onto day 4 and call it Klyuchevskaya. Our planner leaves it out and explains why: operators sell the tour as a whole, it can't be cut to fit your trip, so add days if you want it.

This matters more than it looks. When an LLM builds an itinerary from training data, a gap is a failure, so it fills the gap. When the tool returns an explicit "nothing confirmed here", the assistant has something true to say and no pressure to make things up. In practice the honest gap is what makes the rest of the plan believable.

We also put a hint for the model right in the tool output: "Platform data is in Russian: translate it for the user yourself; do not add facts that are not in this answer." It's a small thing, but it noticeably cuts down on assistants "helpfully" adding details.

Rule 2: safety is part of the plan, not a footnote

Kamchatka isn't a city break. Bears, active volcanoes, protected reserves with permit systems, and seasons that decide what's even possible. So the planner returns safety data as part of each day:

• "guide only" flags for bears and volcano ascents;
• permit requirements and lead times (book 14 days ahead for the reserve);
• minimum distances and mandatory gear;
• warnings tied to the traveller's stated fitness ("volcanoes need good fitness, you said average").

The traveller learns about the 14-day permit lead time while planning, not on arrival. The start date is required context too: the planner works out what's in season from the trip dates, so a November trip won't get a July itinerary.

Rule 3: edit the plan, don't regenerate it

Each plan gets an ID and is stored for 7 days. After that the conversation works with the plan itself through a second tool, edit_trip_plan: add a day, remove or swap a day, change the accommodation level, or handle a flight delay.

We tested the "flight delayed by two days" case. The planner moved the arrival to July 12, kept the original return flight, dropped the days that no longer fit (bears and trekking), and left the other dates alone, because operators run on their own schedules and an edit shouldn't quietly move a confirmed departure.

This is why it's a stateful tool and not one big prompt. If you regenerate a plan every time someone says "make it cheaper", you get a new random plan every time. If you edit by ID, the parts the traveller already agreed to stay put.

What the traveller ends up with

Every plan has its own page with a map, a GPX file for offline navigation apps, and a "save to phone" option for when you're in the field without signal. The tool response links to it directly.

There are also ready-made routes such as Kamchatka in 7 days: bears, ocean and a volcano, where each day is linked to real tours from local operators, with their prices and a request button.

We deliberately left out instant booking and payment through the assistant. The traveller sends the request to the operator themselves, their name and phone number are shared only with their explicit consent, and a real operator confirms the tour. For a trip that involves bears and volcanoes, a person on the other end is a feature.

Under the hood

The MCP server at https://vedarai.ru/api/mcp currently exposes 17 tools. Besides the two planning tools there are:

• get_tours, get_tour_details, get_tour_availability: operator tours and departures
• get_volcano_status, safety_status, get_weather: current conditions
• search_accommodations, search_transfers, search_car_rental, search_gear
• get_place_info, get_guardian_context, get_request_status
• search / fetch for assistants that expect that pair

Tool descriptions are bilingual: English for the model's routing, Russian for the data and examples. The data itself stays in Russian because that's what operators enter, and the model translates it with the "don't add facts" instruction above.

Try it

• Without an assistant: use the planner on vedarai.ru.
• With an assistant: add https://vedarai.ru/api/mcp as a remote MCP connector. No sign-up or API key. Setup steps for Claude, ChatGPT, Cursor and VS Code are at vedarai.ru/mcp.
• Directory listing: Vedar on Glama.

If you're building an MCP server for a small, data-poor niche, the lesson we keep coming back to is simple: give the model a true "we don't know" to say, and it'll stop inventing the rest.

• Website: vedarai.ru
• MCP setup: vedarai.ru/mcp
• Previous post: Why AI assistants don't know small businesses, and how we opened Kamchatka to agents with MCP