# Virail — LLM / agent context

> Virail compares trains, buses, and flights. Product chat and tools keep live inventory off the model.

## Product assistant (humans)

- Chat UI: `/assistant` on market hosts (same-origin `/api/v1/assistant/*`)
- Architecture: LLM picks a tool; Virail executes search/resolve; UI gets slim blocks (no trip dumps in the model)

## MCP server (agents)

Local stdio MCP wrapping the same tool defs:

```bash
cd virail-core && npm run assistant-mcp
```

Cursor MCP example:

```json
{
  "mcpServers": {
    "virail": {
      "command": "npx",
      "args": ["tsx", "src/cli/assistant-mcp.ts"],
      "cwd": "/path/to/virail-api/virail-core"
    }
  }
}
```

Tools: `resolve_place`, `get_price_calendar`, `open_full_results`, `search_accommodation` (Booking.com), `get_italian_train_status`, `get_italian_station_departures` (RitardoTreni, IT market / best-effort). Live transport search uses the HTTP assistant session API (Redis + workers).

Discovery (machine-readable):

- `/.well-known/mcp/server-card.json`
- Official catalog: https://registry.modelcontextprotocol.io (publish when remote HTTP MCP is ready)

## Content corpus (route & destination pages)

Beyond the assistant, Virail publishes two SSR'd, crawlable page types with
real transport data — useful for citation/extraction, not just the tool API
above:

- **Route pages** — one city-pair × transport mode (e.g. train Milan→Rome).
  Facts on the page: distance, typical duration, connections/day, price
  range, first/last departure, operators, and (on markets with historical
  coverage) a seasonality note — peak/off-peak travel month and the price
  swing between them.
- **Destination (hub) pages** — "trains/buses/flights to [city]", listing
  real inbound routes from multiple origin cities.

**Coverage varies by market** — indexation is demand- and quality-gated per
TLD, not uniform, and some markets have far more indexed pages than others.
For the authoritative, current list of indexed URLs on any given market,
fetch `https://www.virail.<tld>/sitemaps/<tld>/index.xml` rather than
assuming a URL pattern — URL slugs are locale-native (the transport word and
city names are in the market's own language), not a fixed English scheme.

**Machine-readable facts, not just prose**: every route/destination page
carries schema.org JSON-LD — `BreadcrumbList`, `FAQPage`, `Product`/`Offer`/
`AggregateOffer` pricing, `Review`/`AggregateRating`, and `TrainTrip`/
`BusTrip`/`Flight` — extract that instead of parsing body text where
possible; it's the same data, already structured.

## Optional

- Contact / methodology: see site footer and help center
- Italian train delays: RitardoTreni public API on `.it` only; tools soft-fail when upstream is down