This server lets you search real Virail transport connections between two places on a given date.
Search live train, bus, flight, ferry, and carpooling options across Europe and beyond.
Requires departure, arrival, and travel date; optional adults, market (tld), locale, and currency.
Returns real schedules, duration, number of transfers, total price, carriers, transport modes, and booking links.
Works from any MCP-compatible AI client via the hosted endpoint, with no API key or installation needed.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@virail-mcp Find train and bus options from Milan to Paris on 2025-06-15"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Virail transport search — trains, buses, flights, ferries, and carpooling across Europe and beyond. Gives any MCP-compatible AI agent (Claude Desktop, Cursor, Claude.ai, etc.) the ability to search real, live travel connections with real prices, schedules, and booking links.
Virail runs this server for you at:
https://virail.ai/mcpNo install, no API key — just point your MCP client at that URL. For clients that support remote MCP servers via a config file, the shape typically looks like:
{
"mcpServers": {
"virail": {
"url": "https://virail.ai/mcp"
}
}
}The exact config key/format for adding a remote MCP server varies by client and changes over time — check your client's own docs for "remote MCP server" or "custom connector" setup if the snippet above doesn't match what it expects. Claude.ai / Claude Desktop, for instance, let you add one directly from Settings without editing a config file at all.
This HTTP endpoint is the only supported way to use virail-mcp right now — there's no local/CLI install.
Step-by-step setup for Claude.ai, Claude Desktop, Cursor, and other clients: virail.ai/mcp-setup.
Related MCP server: mcp-irail
search_transportSearch for connections between two places on a date.
Argument | Type | Required | Description |
| string | yes | Origin city or station name |
| string | yes | Destination city or station name |
| string | yes | Travel date, |
| number | no | Number of adult passengers (default |
| string | no | Virail market, e.g. |
| string | no | Response language, e.g. |
| string | no | Price currency, e.g. |
Returns a list of trip options, each with departure/arrival times and stations, duration, number of transfers, total price, carrier(s), transport mode(s), and a booking link.
npm install
npm run build # compile to dist/
npm test # run unit testsMIT
Search real train, bus, flight, ferry, and carpool connections between two places on a date via Virail. Returns real prices, schedules, and booking links — never invent this data yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| tld | No | Virail market/TLD, e.g. com, it, fr, de, es (default com) | |
| date | Yes | Travel date, YYYY-MM-DD | |
| adults | No | Number of adult passengers, default 1 | |
| locale | No | Response language, e.g. en, it, fr (default en) | |
| arrival | Yes | Destination city or station name | |
| currency | No | Price currency, e.g. EUR, USD (default EUR) | |
| departure | Yes | Origin city or station name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a solid job: it states the tool returns real, non-fabricated data sourced from Virail, including prices, schedules, and booking links. It does not mention rate limits or error behavior, but for a search operation this is adequate.
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 two sentences with no filler. It front-loads the main action and source, then gives the return-value summary and a critical caution, all in an economical 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?
Without an output schema, the description does explain the return values at a high level: real prices, schedules, and booking links. Required arguments are implied by 'between two places on a date,' and the schema covers all parameters. It is complete enough for tool selection and invocation, though it could mention edge cases like empty results.
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 already describes all 7 parameters at 100% coverage, so the description needs no additional parameter details. It reinforces that 'departure' and 'arrival' are two places and 'date' is the travel date, but adds no new semantic beyond the 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 names a specific verb ('Search'), a specific resource ('real train, bus, flight, ferry, and carpool connections between two places on a date via Virail'), and the return type ('real prices, schedules, and booking links'). Even without sibling tools, an agent can unambiguously understand what this tool does.
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 explicitly says to use this tool to get real transport data and 'never invent this data yourself,' which is a clear directive for when the agent should invoke it rather than hallucinate. It lacks explicit exclusion criteria, but with no sibling tools the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
只有一个工具，因此不存在工具之间混淆的可能性。该工具具有清晰、唯一的用途，即搜索交通连接。
该工具遵循清晰的动词_名词模式，易于阅读和预测。由于只有一个工具，没有冲突或混合约定。
单个工具令人感觉单薄，对于交通搜索服务器而言尤其如此，该服务器可能还需要位置查找或行程详情等辅助工具。然而，该工具本身作为一个综合搜索入口，属于边缘情况。
该工具满足了其声明的目的：提供连接、价格、时刻表和预订链接。缺少诸如获取可用路线或筛选运输方式的辅助操作，但这些可能超出了单一搜索工具的范围。
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Ferryhopper MCP server is a connector for LLMs and AI Agents in maritime travel that exposes ferry routes, schedules, and booking options. It enables AI assistants to search ports and connections across 33 countries and 190+ ferry operators, provide real-time ferry itineraries with indicative prices, and assist users with planning island-hopping or multi-leg journeys by processing natural language queries about ferry times, passenger counts, and travel durations.
Search and compare flight offers through a cache-aware Streamable HTTP MCP server for AI agents.
AI marketplace — flights, tours, activities, transport & more via MCP. No auth required.
Live flight prices and working booking links for AI agents and travel apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/viraildev/virail-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
