Travel Agent MCP Server
TravelAgentMCP 🌍✈️
一个用于 TVA OTA 平台的 MCP(模型上下文协议)服务器单体仓库:提供航班和酒店搜索与预订、签证和移民要求及预订跟踪、以及用户账户管理——专为 AI 旅行代理构建。
架构
TravelAgentMCP/
├── mcps/
│ ├── shared/ @travelagent-mcp/shared — HTTP client, config, guardrails, tool helper (not a server)
│ ├── flight-mcp/ tva-flight-mcp — search, pricing, seatmaps, booking lifecycle
│ ├── hotel-mcp/ tva-hotel-mcp — search, availability, booking lifecycle
│ ├── visa-mcp/ tva-visa-mcp — country requirements + booking tracking
│ ├── immigration-mcp/ tva-immigration-mcp — service info + booking tracking
│ └── account-mcp/ tva-account-mcp — auth, profile, promo codes, notifications
└── src/index.ts travelagent-mcp — gateway that mounts all five servers' tools in one process每个 mcps/* 包都是一个独立可运行的 stdio MCP 服务器,带有自己的 bin。运行你需要的那些(例如,仅 tva-flight-mcp + tva-hotel-mcp 用于预订小部件,或仅 tva-visa-mcp + tva-immigration-mcp 用于咨询机器人),或运行根网关(travelagent-mcp)以在一个进程中获取所有功能——这就是已发布的 npm 包一直以来的形式,为向后兼容而保留。
一个上游 API,两种认证模式:
TVA OTA 后端(
TVA_BASE_URL)——航班、酒店、预订、账户,以及签证/移民预订跟踪的“客户端”侧(更新、通知、交易)。大多数预订管理端点需要 bearer 令牌;访客结账流程(预订、按 UUID 取消、验证、重新发送票据)则不需要。签证/移民内容(相同的
TVA_BASE_URL,通过CONTENT_API_KEY而非 bearer 令牌认证)——国家要求、签证类型、费用和常见问题解答,仅由GET_VISA_INFO_BY_COUNTRY/GET_IMMIGRATION_INFO_BY_COUNTRY使用。
Related MCP server: orizn-visa-mcp
防护措施
最小权限:仅暴露面向用户的端点。管理/运营端点(预订管理、退款、收入统计)故意不包装为工具——它们不适合对话式代理。
明确确认:每个涉及资金流动或不可逆的工具(
BOOK_FLIGHT、BOOK_HOTEL、CANCEL_FLIGHT_BOOKING、CANCEL_HOTEL_BOOKING、CONFIRM_FLIGHT_PAYMENT、CONFIRM_HOTEL_PAYMENT、SELECT_FLIGHT_SEAT、CHANGE_PASSWORD、CLOSE_ACCOUNT)都需要confirm: true,调用代理应在向用户回读具体细节后才设置此参数。LLM 上下文中无秘密:
TVA_ACCESS_TOKEN绝不是工具参数——它从进程环境中读取,由生成这些服务器的任何代理按用户会话注入。LOGIN_USER/SOCIAL_AUTH_LOGIN将令牌包装在__session信封中返回,供生成代理拦截并带外存储;模型仅看到一条纯确认消息。请参阅mcps/account-mcp/src/lib/session.ts了解约定。无原始报价重放:Amadeus 航班报价是大型不透明 JSON 块。
SEARCH_FLIGHTS将每个报价缓存在服务器端(SQLite,请参阅mcps/flight-mcp/src/lib/offerCache.ts),并向模型提供一个简短的offerRef——模型永远不会手动重建报价 JSON,这可能会带来令牌膨胀或价格/费用静默损坏的风险。脱敏:密码、令牌、OTP 和卡号在记录任何内容之前都会被屏蔽(请参阅
mcps/shared/src/guardrails.ts)。已知风险——酒店支付:
BOOK_HOTEL当前直接接收原始卡详细信息(TVA 酒店 API 尚无令牌化结账步骤)。这必须仅由通过符合 PCI 标准的表面收集了卡详细信息的客户端调用——绝不能通过提示用户在聊天中键入卡号来调用。请参阅工具描述了解详情。速率限制:每个工具调用按进程进行节流(防止失控的函数调用循环)。这不能替代持久的、跨轮次的节流——如果你需要真正的保护,请在会话层持久跟踪滥用情况。
设置
pnpm install
cp .env.example .env # fill in TVA_BASE_URL and content-API keys
pnpm build # builds mcps/shared first, then every domain server, then the gateway运行网关(一个进程中的所有工具):
pnpm start或直接运行单个域服务器:
node mcps/flight-mcp/dist/index.js工具参考
航班(tva-flight-mcp)
SEARCH_FLIGHTS、GET_POPULAR_FLIGHT_ROUTES、GET_FLIGHT_PRICE_ANALYSIS、GET_MOST_TRAVELED_DESTINATIONS、GET_MOST_BOOKED_DESTINATIONS、GET_BUSIEST_TRAVEL_PERIOD、GET_FLIGHT_SEATMAP_BY_OFFER、GET_FLIGHT_SEATMAP_BY_ORDER、GET_FLIGHT_FARE_UPSELL、PREDICT_FLIGHT_CHOICE、CONFIRM_FLIGHT_PRICE、BOOK_FLIGHT、LIST_MY_FLIGHT_BOOKINGS、GET_FLIGHT_BOOKING、VERIFY_FLIGHT_BOOKING、CANCEL_FLIGHT_BOOKING、GET_FLIGHT_SEAT_PRICE、SELECT_FLIGHT_SEAT、RESEND_FLIGHT_TICKET、GET_FLIGHT_TICKET_DOWNLOAD_LINK、CONFIRM_FLIGHT_PAYMENT
酒店(tva-hotel-mcp)
SEARCH_HOTELS、SEARCH_HOTEL_CITIES、CHECK_HOTEL_AVAILABILITY、BOOK_HOTEL、LIST_MY_HOTEL_BOOKINGS、GET_HOTEL_BOOKING、CONFIRM_HOTEL_PAYMENT、CANCEL_HOTEL_BOOKING
签证(tva-visa-mcp)
GET_VISA_INFO_BY_COUNTRY、LIST_MY_VISA_BOOKINGS、GET_VISA_BOOKING、GET_VISA_BOOKING_BY_APPLICATION_UUID、GET_VISA_UPDATES、GET_VISA_UPDATES_BY_BOOKING、GET_VISA_FOLLOWUP_QUESTIONS、ANSWER_VISA_FOLLOWUP、GET_VISA_NOTIFICATIONS、MARK_VISA_NOTIFICATION_READ、GET_VISA_TRANSACTIONS、GET_VISA_TRANSACTION_DETAIL
移民(tva-immigration-mcp)
GET_IMMIGRATION_INFO_BY_COUNTRY、LIST_MY_IMMIGRATION_BOOKINGS、GET_IMMIGRATION_BOOKING、GET_IMMIGRATION_UPDATES、GET_IMMIGRATION_UPDATES_BY_BOOKING、GET_IMMIGRATION_NOTIFICATIONS、MARK_IMMIGRATION_NOTIFICATION_READ、GET_IMMIGRATION_TRANSACTIONS、GET_IMMIGRATION_TRANSACTION_DETAIL
账户(tva-account-mcp)
REGISTER_USER、LOGIN_USER、SOCIAL_AUTH_LOGIN、FORGOT_PASSWORD、RESEND_OTP、VERIFY_OTP、LOGOUT_USER、GET_CURRENT_USER、GET_USER_PROFILE、EDIT_USER_PROFILE、CHANGE_PASSWORD、CHECK_DISCOUNT_PROMO、GET_USER_NOTIFICATIONS、CLOSE_ACCOUNT
被以下项目使用
MegaMind 的 NomadSage 旅行代理生成这些服务器(通过 stdio,每个域一个),以及其知识库搜索和 social-mcp 回复工具——请参阅该仓库中的 travel-agent/src/lib/tva-client.ts 和 travel-agent/src/lib/tva-session.ts。
Available Tools
2 toolsGET_IMMIGRATION_INFO_BY_COUNTRYC
Get immigration information for a specific country.
| Name | Required | Description | Default |
|---|---|---|---|
| countryCode | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get' which implies a read-only operation, but does not disclose any behavioral traits such as rate limits, authentication needs, data freshness, or error handling. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized and front-loaded, efficiently conveying the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of immigration information, lack of annotations, no output schema, and low schema coverage, the description is incomplete. It does not address what type of information is returned, potential limitations, or how it differs from the sibling tool, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not add any meaning beyond the schema. It mentions 'specific country' but does not explain the 'countryCode' parameter's format, valid values, or semantics, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'immigration information for a specific country', making the purpose understandable. However, it does not explicitly differentiate from its sibling tool GET_VISA_INFO_BY_COUNTRY, which likely provides overlapping or related information, so it misses the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its sibling GET_VISA_INFO_BY_COUNTRY, nor does it mention any prerequisites or alternative contexts. It lacks explicit usage instructions, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GET_VISA_INFO_BY_COUNTRYC
Get visa information for a specific country.
| Name | Required | Description | Default |
|---|---|---|---|
| countryCode | Yes | ||
| currencyCode | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action without details on permissions, rate limits, error handling, or response format. It doesn't add meaningful context beyond the minimal purpose, failing to compensate for the lack of structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration, earning full marks for brevity and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no output schema, and no annotations), the description is insufficient. It lacks details on parameter usage, behavioral traits, and output expectations, making it incomplete for effective agent operation despite the concise structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description doesn't mention any parameters or their meanings. It fails to explain what 'countryCode' and 'currencyCode' represent, their expected formats, or how they influence the output, leaving both parameters undocumented and adding no value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('visa information for a specific country'), making it immediately understandable. However, it doesn't explicitly differentiate from its sibling tool 'GET_IMMIGRATION_INFO_BY_COUNTRY', which likely covers related but distinct information, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its sibling 'GET_IMMIGRATION_INFO_BY_COUNTRY', nor does it mention any prerequisites, alternatives, or exclusions. It only states what the tool does, leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
GET_IMMIGRATION_INFO_BY_COUNTRY - First observed
GET_VISA_INFO_BY_COUNTRY
TDQS
Scored across 2 tools
The two tools have unclear boundaries and significant overlap. 'Immigration information' and 'visa information' are closely related concepts in travel, and their descriptions do not clearly differentiate what each tool provides, leading to potential confusion for an agent trying to select the right one.
The tool names follow a consistent pattern of uppercase snake_case with a clear 'GET_<domain>_BY_COUNTRY' structure. Both tools use the same verb ('GET') and format, making them predictable and easy to parse.
With only 2 tools, the server feels thin for a 'Travel Agent' domain, which typically involves broader functionality like booking flights, hotels, or checking travel advisories. The limited scope suggests an incomplete or overly narrow implementation.
The server is severely incomplete for a travel agent purpose. It lacks core travel operations such as searching for flights, booking accommodations, checking weather, or providing general travel tips, leaving obvious gaps that will hinder agent workflows.
Related MCP Connectors
Visa requirements, fees, stay limits and extension rules for any passport and destination
Plan trips and track visa days per traveller across 39,601 entry rules
Your personal AI travel concierge — flights, hotels, 116M+ POIs, visas, weather & more
Passport visa, entry & transit requirements for any country pair, with official government sources.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceProvides tools to retrieve and compare detailed information about countries, including population, region, and currency data. It allows users to search for specific countries or list them by region.-
- AlicenseAqualityCmaintenanceCheck visa requirements for 39,585 passport-destination pairs in 15 languages. Returns visa type, required documents, application process, and travel tips from 136 official government sources. Free quick checks without API key.5142 npm1MIT
- AlicenseAqualityDmaintenanceProvides immigration eligibility intelligence, enabling AI assistants to match user profiles to visas, compare pathways, and get country overviews using Transita's API.5316 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables querying passport visa rules for any nationality to destination pair.100 npmMIT