DEV Community: Vedar

用 MCP 把俄罗斯一个地区的小旅行社接入 AI 智能体：22 个工具的实践

Vedar — Sun, 25 Oct 2026 00:37:27 +0000

问题：AI 不认识小商家

问大模型“堪察加有什么火山徒步线路、下周有没有位置”，它一般会给你一段概括性的介绍，然后建议你“联系当地旅行社”。原因很简单：堪察加的旅行社大多是几个人的小团队，信息散在俄语网站、Telegram 频道和电话里，搜索引擎抓不全，模型训练数据里更没有实时的余位和价格。

我们做的 Vedar（vedarai.ru）是堪察加本地的旅行平台，汇总了当地旅行社的线路、包车、租车和住宿。网站本身对人是友好的，但我们发现越来越多的用户在用 AI 助手规划旅行，于是决定把平台直接开放给 AI 智能体——用的就是 MCP（Model Context Protocol）。

架构：一个远程 MCP 服务器

接入地址：https://vedarai.ru/api/mcp
传输：Streamable HTTP
鉴权：无（查询类全部只读）
文档：https://vedarai.ru/mcp
仓库：https://github.com/tourhabk-ui/vedar-mcp （有中文 README）

我们没有让 MCP 去爬自己的网页，而是让工具直接读平台的业务数据：线路目录、实时余位、合作方的住宿和车辆。这样 AI 拿到的价格和日期就是旅行社在后台维护的那一份，不会出现“网页改了、AI 还在说旧价格”的问题。

22 个工具，分三类

tools/list 当前返回 22 个工具：

1. 查询（只读）

get_tours、get_tour_details、get_tour_availability：线路、详情、实时余位
search_accommodations、search_transfers、search_car_rental、search_gear：住宿、包车、租车、装备
search + fetch：通用检索，兼容只认这两个工具名的客户端
get_place_info：地点名称、类型、坐标

2. 安全与环境

get_weather：按天预报（Open-Meteo），支持地名或经纬度
get_volcano_status：KVERT 航空颜色代码 + 俄罗斯科学院地球物理局地震数据
safety_status、get_guardian_context：全区预警（地震、火山、天气、紧急情况部）和某条路线的风险提示

3. 规划与申请

make_trip_plan / edit_trip_plan：结合天气和余位生成按天行程，返回计划 ID，后续可以只改某一天
create_lead、create_booking_request、create_stay_request、request_charter、create_car_rental_request、get_request_status：提交申请、查询进度

几个设计取舍

不收钱，只提交申请。 所有 create_* 工具只创建一份申请，由旅行社或承运人人工电话确认，平台不在线收款。对 AI 来说，“替用户下单付款”风险太大；“替用户把需求整理好交给真人”刚好合适。

个人信息必须显式同意。 只有参数里带 consent: true 时才会发送联系方式。租车申请更严格，分两步：第一步返回草稿和确认码，第二步需要用户本人明确同意才提交。

价格只来自目录。 我们要求工具返回的价格必须对应目录里的具体线路并附链接，不让模型自己“估一个区间”。旅游场景里，一个编出来的价格比没有价格更糟。

行程留空天。 make_trip_plan 会在一周行程里主动留一天备用。堪察加的直升机和出海经常因天气取消，这是当地向导的经验，我们把它写进了规划逻辑。

安全数据和线路放在一起。 火山预警升级时，模型在推荐相关线路的同一轮对话里就能看到预警，而不是让用户自己去别处查。

接入配置

支持远程 MCP 的客户端（Claude Desktop、Cursor 等）：

{
  "mcpServers": {
    "vedar": {
      "url": "https://vedarai.ru/api/mcp"
    }
  }
}

只支持 stdio 的客户端，用 mcp-remote 转一下：

{
  "mcpServers": {
    "vedar": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://vedarai.ru/api/mcp"]
    }
  }
}

不装客户端，先用 curl 看看工具列表：

curl -s -X POST https://vedarai.ru/api/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

一个实际场景

今年 10 月，伊尔航空开通了哈尔滨直飞堪察加的航线（每周六），中国公民入境俄罗斯又可以免签停留 30 天。用户在 AI 助手里说“周六从哈尔滨飞堪察加，玩一周，想看火山”，智能体可以依次调用 safety_status 看预警、get_tours 和 get_tour_availability 找有位置的线路、make_trip_plan 排出“周六到周六”的行程，最后用 create_booking_request 把申请交给旅行社。整个过程中，价格、日期、预警都来自实时数据。

写在最后

对小商家来说，MCP 的意义不在于技术多新，而在于门槛低：一个 HTTP 端点，就能让所有支持 MCP 的 AI 客户端“认识”你。如果你也在做本地生活、旅游或者其他长尾行业，欢迎参考我们的仓库，也欢迎提 Issue 交流。

仓库：https://github.com/tourhabk-ui/vedar-mcp
中文站：https://vedarai.ru/zh

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

Vedar — Sat, 24 Oct 2026 23:25:21 +0000

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

Why AI assistants don't know small businesses, and how we opened Kamchatka to agents with MCP

Vedar — Fri, 23 Oct 2026 23:25:10 +0000

AI assistants are getting good at planning trips. Ask one about Kamchatka, though, and you get Booking, Viator, GetYourGuide and a few generic tour agencies. The small local operators who actually run the volcano climbs and the bear-watching trips mostly don't show up. We build Vedar (vedarai.ru), a travel platform for Kamchatka, Russia: tours from local operators, stays, transfers, self-drive car rental, volcano status and route safety. This post covers how we opened all of it to AI agents through an open MCP server, and what we learned along the way.

The problem: assistants don't know small businesses

We asked four models (GPT-4o mini, Claude Haiku 4.5, Qwen3 and DeepSeek V3.1) the same question in Russian, English and Chinese: "Which services help plan a trip to Kamchatka?" None of them named Vedar: 0 out of 12 answers. We repeated the test four times between October 18 and 23, and got 0 out of 12 every time.

Then we gave the same models our MCP server. In 12 of 12 runs the assistant called our tools by itself and built a day-by-day trip. In 9 of 12 the answer contained our real data: prices, permit requirements, rules for areas with bears.

So the lesson is simple. Models can already use your service. They just won't find out about it on their own. Those are two separate problems, and only the first one is solved with code.

MCP and A2A in plain words

MCP (Model Context Protocol) is a common "socket" that lets an AI assistant plug into an outside service. Without it, the assistant only knows what it read during training. With it, the assistant can ask the service mid-conversation, "what tours are there in July?", and get a live answer.

A2A (Agent2Agent) is for two agents talking to each other. With MCP, an assistant picks up a tool. With A2A, one agent asks another agent for help, the way you'd ask a colleague. The agent publishes a card listing its skills, accepts a task and returns a result.

What Vedar exposes: 22 tools

Endpoint: https://vedarai.ru/api/mcp. It's Streamable HTTP, and you don't need to sign up or get a key. The server is at version 2.7.0, and this is the live tools/list:

Tours: get_tours (catalog with prices), get_tour_details (program, what's included, what to bring), get_tour_availability (free seats by date).
Safety: safety_status (regional alerts: seismic, volcanic, weather, emergency service), get_volcano_status (KVERT aviation codes and seismicity), get_guardian_context (hazards and advice for a specific place or route).
Places and weather: get_place_info, get_weather, plus search and fetch across the whole base.
Logistics: search_accommodations, search_transfers (whole-vehicle charters: vakhtovka, minibus, jeep), search_car_rental (self-drive SUVs, 4x4s, minibuses), search_gear.
Trip plans: make_trip_plan (day by day, with weather and live availability) and edit_trip_plan.
Requests, always confirmed by a human: create_lead, create_booking_request, create_stay_request, request_charter, create_car_rental_request, plus get_request_status.

Here's a real get_tours response from October 24, 2026, when an assistant asked about volcano tours:

Consent comes first

Assistants can't book instantly or take payment. Every request goes to a real operator, who confirms it. A traveler's name and phone number only reach the operator with that person's explicit consent.

The car rental request goes one step further and works in two steps. The first call to create_car_rental_request returns a draft and a confirmation code that's valid for 30 minutes. The assistant shows the draft to the person. Only the second call, with the same fields, the code and consent: true, actually sends the request. That way an agent can't send someone's details on its own.

How to connect

Any MCP client. Run npx vedar-mcp (npm) to print a ready config:

{
  "mcpServers": {
    "vedar": {
      "type": "http",
      "url": "https://vedarai.ru/api/mcp"
    }
  }
}

Cursor / VS Code: add the block above to your MCP config, or use the one-click install buttons on vedarai.ru/mcp.

Claude Desktop / claude.ai: add a custom connector with the URL https://vedarai.ru/api/mcp. It doesn't need authentication.

Claude Code:

claude mcp add --transport http vedar https://vedarai.ru/api/mcp

A2A agents: the agent card is at vedarai.ru/.well-known/agent-card.json. Calls go to https://vedarai.ru/api/a2a (JSON-RPC) or https://vedarai.ru/api/a2a/v1 (REST), using A2A 1.0.

You'll also find the server on Glama, and code examples are on GitHub.

Why assistants make things up

When we asked models directly, "do you know Vedar?", they often didn't say "I don't know". In the latest check, 8 of 12 answers were honest or cautious and 4 of 12 were made up. None was correct. One model called us a "B2B platform". Another expanded MCP as "Master Channel Partner". Here's what has helped us so far:

One honest description of yourself, the same everywhere. Ours lives at vedarai.ru/llms.txt.
Catalogs and registries. We're listed in MCP registries and directories such as Glama.
Mentions from other people. One link from a real partner carries more weight than ten pages on your own site.
Regular, honest testing. Ask several assistants about your niche without naming yourself, and repeat the check.

For travelers

You don't need to be a developer. Connect Vedar to your assistant once, then ask in plain language: "a 7-day Kamchatka trip in July with a volcano climb", "a 4x4 rental in Petropavlovsk", "is it safe to go to Avachinsky this week?". The answers come from live operator data, and nothing gets booked without your say.

Website: vedarai.ru
MCP: https://vedarai.ru/api/mcp
npm: vedar-mcp
Glama: ru.vedarai/mcp
Channel about vibe coding and AI agents (in Russian): Telegram · MAX
The original Russian article on vc.ru: Why AI doesn't know your service