The Kamchatka MCP server is a small, real answer to a big problem: AI assistants know almost nothing about tiny local businesses. The team behind Vedar, a travel platform for Russia’s Kamchatka peninsula, opened its catalog to AI agents through 22 tools on a public endpoint, and wrote up what they learned on 25 October 2026.
Ask a chatbot for volcano hikes and free spots next week, and you usually get a generic overview and the advice to “contact a local agency”. This project tries to close that gap.
Key takeaways
- Vedar exposes 22 tools through a remote MCP server using Streamable HTTP, with no login for read-only queries.
- The tools read the platform’s business data directly instead of scraping web pages.
- Prices come only from the catalog. The model is not allowed to estimate ranges.
- Nothing is booked or paid online: the “create” tools submit requests, and a human confirms by phone.
- Safety data (weather, volcano status, alerts) travels in the same conversation turn as tour results.
Why can’t AI assistants help with small travel agencies?
Kamchatka’s operators are mostly teams of a few people. According to the Vedar developers’ write-up on dev.to, their information is scattered across Russian-language sites, Telegram channels and phone calls. Search engines miss much of it, and no training set contains live seat counts or current prices.
Vedar already aggregated routes, transfers, car rentals and lodging for people. The new step was making that same data usable by agents.
How does the Kamchatka MCP server work?
MCP, the Model Context Protocol, is an open standard that lets AI apps call external tools. Think of it as a USB port for assistants: any compliant client can plug into any compliant server.
Vedar runs a remote server at vedarai.ru/api/mcp. It uses Streamable HTTP, one of the two standard transports in the MCP specification, which replaced the older HTTP+SSE approach. Clients that only speak stdio can bridge in with the mcp-remote package.
The key design choice: the tools do not crawl the website. They query the same business data operators maintain, so an agent sees the same prices and dates a human would.
What do the 22 tools actually do?
| Group | Count | Examples |
|---|---|---|
| Queries (read-only) | 10 | get_tours, get_tour_availability, search_accommodations, search_car_rental |
| Safety and environment | 4 | get_weather, get_volcano_status, safety_status, get_guardian_context |
| Planning and requests | 8 | make_trip_plan, edit_trip_plan, create_booking_request, get_request_status |
Two query tools, search and fetch, exist only because some clients expect those exact names. The safety group pulls from Open-Meteo for forecasts, plus volcano aviation color codes and seismic data from Russian scientific sources, as the authors describe it.
Which rules keep the agent honest?
The most useful part of the write-up is its list of guardrails. Each one is cheap to copy.
- Catalog-only prices. A price must match a specific route and include a link. The authors’ view is that a made-up price is worse than no price.
- One buffer day.
make_trip_planleaves a day free, because helicopter and boat trips are often cancelled for weather. - Safety beside results. Warnings show up in the same turn as the tour list, so the model cannot skip them.
- Consent for personal data. Personal details move only when
consent: trueis set, and car rentals need a second confirmation with a code. - Requests, not bookings. The create tools submit a request. A human operator confirms by phone, and the platform takes no online payments.
That last rule is the sensible one for a region where one cancelled flight rewrites the plan. An agent that promises a confirmed seat it cannot guarantee does more harm than a chatbot that says nothing.
Is this the right way to design an MCP server?
Mostly yes, and it matches what larger teams report. In a write-up on the Kiwi.com MCP server, the argument is that these servers are not just API wrappers and need deliberate design for how language models behave, with context efficiency a priority.
Opinion: 22 tools is on the high side. Models pick tools by reading descriptions, and every extra tool is more text to read and more room for a wrong choice. Grouping by task, as Vedar does, helps, but I would watch for tool-selection mistakes as the list grows.
The wider industry is also still early. PhocusWire’s look at how MCP could reshape travel shows the protocol being discussed mainly in terms of big platforms. A regional operator shipping a working server is a useful counterexample.
What happens next
The pattern should spread to other places with the same shape: many small operators, scattered data, and risks that change by the hour. Think ski guides, island ferries or regional guesthouses.
Related reading on Nerdlyst: how WebMCP on Commerce.com opens stores to agents, how Supabase’s MCP server keeps agents inside row-level security, and how QAmcp scores an MCP server before you ship it.
FAQ
Does the Kamchatka MCP server take payments?
No. The create tools only submit requests, and an operator or carrier confirms by phone.
Do you need an account to use it?
No. The query tools are read-only and need no authentication. Sharing personal data requires an explicit consent flag.
Can my own small business do the same?
Yes. Start with a few read-only tools over your real data, add safety or availability context, and keep any write action as a request a human approves.
Your next step: list the three questions customers ask most, and build one read-only tool for each before adding anything else.
Leave a comment