Travel Agent MCP Server
TravelAgentMCP 🌍✈️
TVA OTAプラットフォーム向けのMCP(Model Context Protocol)サーバーのモノレポ:フライトとホテルの検索・予約、ビザと入国要件・予約追跡、ユーザーアカウント管理 — 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/*パッケージは、独自のbinを持つ独立して実行可能なstdio MCPサーバーです。必要なものだけを実行するか(例:予約ウィジェット用にtva-flight-mcp + tva-hotel-mcpのみ、またはアドバイザリーボット用にtva-visa-mcp + tva-immigration-mcpのみ)、ルートのゲートウェイ(travelagent-mcp)を実行してすべてを1つのプロセスで取得します。これは公開されているnpmパッケージが常にそうであったもので、後方互換性のために維持されています。
1つのアップストリームAPI、2つの認証モード:
TVA OTAバックエンド(
TVA_BASE_URL)— フライト、ホテル、予約、アカウント、およびビザ/入国予約追跡の「クライアント」側(更新、通知、トランザクション)。ほとんどの予約管理エンドポイントはベアラートークンを必要としますが、ゲストチェックアウトフロー(予約、UUIDによるキャンセル、確認、チケット再送)は必要としません。ビザ/入国コンテンツ(同じ
TVA_BASE_URL、ベアラートークンの代わりにCONTENT_API_KEYで認証)— 国の要件、ビザの種類、料金、FAQ。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ゲートウェイを実行する(すべてのツールを1つのプロセスで):
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経由で、ドメインごとに1つ)ナレッジベース検索や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.
Maintenance
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.-
- AlicenseAqualityBmaintenanceCheck 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 gradedqualityBmaintenanceEnables querying passport visa rules for any nationality to destination pair.190 npmMIT