mcpbeat

Travel Trends MCP Server

eu.mmatinca/travel-trends-mcp
answering

Travel Trends MCP is answering right now. Last checked 9 min ago. It exposes 8 tools.

European tourism & travel-disruption MCP: trip risk, live events, Eurostat panels, RO county data.

Uptime history 39 hours of history
39 hours agonow
100.0%
Uptime 24h
91 of 91 checks
8
Tools
read from the server
101 ms
Response time
average over 24h
open, no key
Access
streamable-http

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 9 min ago.

run in your terminal
claude mcp add travel-trends-mcp --transport http https://travel-trends.mmatinca.eu/mcp/v1
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "travel-trends-mcp": {
      "url": "https://travel-trends.mmatinca.eu/mcp/v1"
    }
  }
}
~/.codex/config.toml
[mcp_servers.travel-trends-mcp]
url = "https://travel-trends.mmatinca.eu/mcp/v1"
.cursor/mcp.json
{
  "mcpServers": {
    "travel-trends-mcp": {
      "url": "https://travel-trends.mmatinca.eu/mcp/v1"
    }
  }
}
.vscode/mcp.json
{
  "mcpServers": {
    "travel-trends-mcp": {
      "url": "https://travel-trends.mmatinca.eu/mcp/v1"
    }
  }
}

Available tools 8

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

country
country_briefing
Get today's published daily briefing, pre-formatted for end users. Returns the same payload as the underlying daily briefing artifact: headline counts, one plain-language headline per active event, monitoring coverage (sources_ok / blind_spots_count), backtest trust figures, and a caveats list. Always relay caveats alongside numbers. Optional ``country`` (EU-27 ISO2 alpha-2, Greece = "EL") narrows the events list only — headline_counts / monitoring / trust stay EU-27-wide, as flagged in the returned note. Missing artifact returns ``{"error": "unavailable"}``.
country_tourism_profile
Tourism profile for one EU-27 country — a decade of Eurostat data. Pure projection of the published artifacts (countries/<code>.json + competitiveness.json): yearly nights/arrivals totals with YoY, average stay, seasonality (peak month and peak-to-mean ratio, formula disclosed), domestic vs foreign visitor share, recovery vs 2019, growth vs the EU average, and computed competitiveness insights (each labeled with its basis). Every number is computed from the same public dataset the site serves — nothing narrated, nothing estimated; links carry the citable page + raw JSON. `code` is EU-27 ISO2 (Greece = "EL"). Unknown country -> {"error": "unknown_country"}; missing artifact -> {"error": "unavailable"}.
assess
assess_trip
Decision support for ONE trip: "should I care?", answered honestly. Give the destinations and the travel window (date_from/date_to, YYYY-MM-DD). Destinations are the EU-27 ISO2 codes (Greece = "EL") PLUS the non-EU27 countries we actively monitor: Norway ("NO", rail via Entur, live), the United Kingdom ("UK" or "GB", transit via TfL, live), and Switzerland ("CH", rail via SBB — key-pending, so it is reported as a declared blind spot until the feed is keyed, never a false all-clear). A code we do not monitor is rejected with {"error": "unknown_country"} rather than silently all-cleared. Returns a Decision-Support answer, not raw data: * travel_status: NORMAL | MINOR_DISRUPTION | MAJOR_DISRUPTION; * actionable_lines: per-event DECISION-IMPACT guidance — what the disruption means for THIS trip and what to do (e.g. "affects regional trains, not airports -> take a road airport transfer, leave ~30 min earlier"), or a clearly-labelled "nothing material" line when calm; * confidence: a LABELLED model output (coverage/corroboration/recency/ blind-spots blend, not a probability) — read its caveats; * sources_checked: proof of what was monitored (sources_ok, blind spots); * events + caveats. Sub-floor noise (a deep, far-field seismic blip) is omitted; calm is a monitoring result for the window, never an invented forecast. Invalid inputs return an explicit {"error": ...}; nothing is fabricated. Top-level MCP-facing structure (additive; existing fields preserved): * presentation: a three-section block — affects_your_trip[] (each item with verified_sources[] as display-ready names, source_count, corroborated flag (≥2 distinct sources), an honest for_you line bound to destinations+dates only, report_url, first_detected_at, last_verified_at); doesnt_affect_your_trip (the proof-of-work pile — shown[] of {headline, reason_excluded}, additional_checked_count, summary_line, total_checked); next_steps[] (deterministic — re-check date, aviation-handoff watch when blind spot, per-active monitor URLs); * track_record_ref: lean {window_days, flagged, ended, still_active, monitoring_since, url} — numbers + URL only, no narrative; * suggested_next_call: factual {tool, context} continuity hint to watch_trip — no claim narrative, just the suggested next action. These exist so an LLM consumer can quote verbatim — every fact is traceable to a named source or an input field, never invented. Destinations also accept natural input: IATA airport codes (e.g. 'TSR', 'AMS', 'ZRH') and major city names (e.g. 'Timișoara', 'Amsterdam', 'Zürich', 'London'), resolved deterministically to a monitored country code. The response includes a 'resolved' list ([{input, country, kind}]) disclosing how each token was mapped (e.g. 'TSR -> RO via iata-airport'). A token that resolves to a country we do not monitor is rejected with {'error': 'unknown_country'}; a token we cannot resolve at all is rejected with {'error': 'unknown_destination', 'tokens': [...]} — we reject rather than guess. Pass `lang` (e.g. "de", "ro", "pl", "fr", "es", "it"; default English) to answer in the TRAVELLER'S language — highest-value for a foreign traveller in a country whose language they do not speak. The response then carries a `localized` block with the status sentence, an honest reassurance line (calm ONLY when status is NORMAL), the decision-impact lines, AND — never dropped — the localized caveats + blind_spots. Source-derived free text the traveller cannot read (an event headline in the source language) is AI-translated via Gemini and carries the label "AI-translated — verify against the linked official source"; when no GEMINI_API_KEY is set or a translation fails, the original source text is kept with an honest note — never a fake translation. Our own wording falls back to English (flagged in `localized.fallback_lang_parts`) when no template exists for `lang`; an unknown `lang` answers in English and says so (`is_known_lang=false`). Localization NEVER becomes a false all-clear and the aviation handoff is a SIGNPOST that DISCLOSES the blind spot, not coverage. Pass `audience` for role-specific operational actions (B2B travel-risk / duty-of-care): one of "tmc" (travel management company / corporate travel risk), "hotel", "ota", "tour_operator". The response then carries a `persona` block: {audience, actions[]} where each action ties an affecting event to that role's recommended steps (e.g. TMC: flexible-rebooking policy, reroute inventory, proactive guest comms) — a PURE PROJECTION of the audience-tagged recommendations already computed per event, each carrying a `based_on` disclosure of the inputs it used. An unknown audience is reported honestly with the valid set, never guessed. Omit `audience` for the default (no persona block).
events
list_events
List detected travel-disruption events for EU-27 tourism. Events are deterministic, rule-based detections over published live snapshots and monthly indicators — thresholds are disclosed in each event record; nothing is model-generated here. Filters: status (e.g. "active"/"resolved"), country (EU-27 ISO2, Greece = "EL"), domain (e.g. "weather", "aviation"), min_severity on the ordered scale info < watch < warning < severe. Returns {count, events, filters}; on missing index returns {"error": "unavailable"}.
explain
explain_silence
Why you heard nothing — the SILENCE AUDIT for a calm watched trip. Answers 'why didn't I hear from you?' honestly, which a stateless model cannot: {recheck_count, last_checked} (we WERE monitoring), {suppressed:[{what, domain, country, score, floor, reason}]} (what we saw for your destinations and dropped below the disclosed relevance floor — e.g. a deep quake at modelled felt-intensity 3.39 < floor 4.0), {confidence_during_window}, and {blind_spots:[{domain, country, note}]} — domains/countries we do NOT monitor live, so silence there is NOT a guarantee (e.g. aviation-IT blind spot => silence does not cover flights). `since` optionally scopes the recheck window. Id is regex-validated; unknown -> {"error": "not_found"}, malformed -> {"error": "invalid_trip_id"}.
trip
get_trip_updates_since
The watched-trip updates log filtered to entries AFTER `since`. The notification payload: everything logged for the trip strictly after the `since` ISO-8601 timestamp (the user's last-seen time), oldest-first. Returns {trip_id, since, new_update_count, updates}. Use this to push only what is new since the user last looked. An empty `since` returns the whole log. Id is regex-validated (^trip-[a-z0-9-]+$); unknown id -> {"error": "not_found"}, malformed id -> {"error": "invalid_trip_id"}.
watch
watch_trip
Watch a trip over time — the continuity primitive a chat cannot match. Persists the trip as a MONITORED OBJECT and returns its initial assessment plus a stable trip_id. Idempotent on identity: re-watching the same destinations+window refreshes the same trip rather than duplicating it. Thereafter each pipeline run re-evaluates the trip and appends an update ONLY when something materially changes (a new/cleared event, a severity/status shift, or a travel_status change) — never on a calm tick. Args: destinations — EU-27 ISO2 codes (Greece = "EL") plus the non-EU27 countries we monitor: Norway "NO" (Entur, live), United Kingdom "UK"/"GB" (TfL, live), Switzerland "CH" (SBB, key-pending → declared blind spot until keyed); date_from/date_to (YYYY-MM-DD); optional label. An unmonitored code is rejected with {"error": "unknown_country"} rather than a false all-clear. Returns {trip_id, assessment, created_at}; invalid inputs return an explicit {"error": ...}. Destinations also accept natural input: IATA airport codes (e.g. 'TSR', 'AMS', 'ZRH') and major city names (e.g. 'Timișoara', 'Amsterdam', 'Zürich', 'London'), resolved deterministically to a monitored country code. The initial assessment includes a 'resolved' list ([{input, country, kind}]) disclosing how each token was mapped (e.g. 'TSR -> RO via iata-airport'). A token that resolves to a country we do not monitor is rejected with {'error': 'unknown_country'}; a token we cannot resolve at all is rejected with {'error': 'unknown_destination', 'tokens': [...]} — we reject not guess. Pass `lang` (e.g. "de", "ro", "pl"; default English) to localise the initial assessment into the traveller's language: the returned assessment carries the same `localized` block as assess_trip (honest reassurance, AI-translated-and-LABELLED source text, and the localized caveats + blind_spots that are never dropped). Localization never becomes a false all-clear; the aviation handoff discloses the blind spot, not coverage. Pass `audience` ("tmc" | "hotel" | "ota" | "tour_operator") for role-specific operational actions — the initial assessment then carries the same `persona` block as assess_trip (audience + per-event role actions, projected from the audience-tagged recommendations). Built for the B2B travel-risk buyer. Pass `notify_webhook_url` (https only) to get PUSH delivery: on every MATERIAL change the radar POSTs the update record (summary, status transition, event report URLs) to your URL, signed HMAC-SHA256 over the raw body (header X-TravelTrends-Signature: sha256=<hex>). The response then includes `notify.secret` — shown ONLY once, never published; store it to verify signatures. Re-watch with the same URL keeps the secret, a new URL rotates it, and notify_webhook_url="" removes delivery. After 5 consecutive delivery failures the webhook is disabled with an honest notify_disabled entry in the trip's updates log. Non-https or private-network URLs are rejected with {"error": "invalid_webhook_url"}.
whats
whats_changed
What changed for a watched trip since last time — ONLY the delta. The continuity payload a memoryless chat cannot produce: recomputes the trip's current assessment and diffs it against the checkpoint at/just- before `since` (or the last evaluation when `since` is omitted). Returns {material, summary, added_events, removed_events, changed_events, previous_travel_status, travel_status, confidence_from, confidence_to}. `summary` is a plain-language line ('Since your last check: rail strike CONFIRMED (was: announced); a road closure cleared; confidence 63->71%'). A non-material tick returns material=False with a clearly-flagged 'No material change' summary — never invented churn. `since` is an optional ISO-8601 timestamp (e.g. the user's last-seen time). Id is regex-validated (^trip-[a-z0-9-]+$); unknown id -> {"error": "not_found"}, malformed id -> {"error": "invalid_trip_id"}. The response also forwards the MCP-facing moat blocks from the current assessment so the LLM consumer has full context alongside the delta: presentation (affects_your_trip / doesnt_affect_your_trip / next_steps), track_record_ref (90-day counts + URL), and suggested_next_call (factual continuity hint). Forwarded in both material=True and material=False branches; absent if upstream did not compute them (legacy code paths) — never fabricated. `audience` (optional: tmc | hotel | ota | tour_operator) attaches the same `persona` block as assess_trip/watch_trip to the change alert — audience-tagged actions for the events currently affecting the trip, so the alert itself carries the operational next step. Unknown audience -> honest error listing valid_audiences.

Endpoints

URLTransportStateLatencyChecked
https://travel-trends.mmatinca.eu/mcp/v1 streamable-http answering 115 ms 9 min ago

Travel Trends MCP — questions

Answers built from our own checks of this server.

What can Travel Trends MCP do?
It exposes 8 tools, read directly from the server on our last check. Among them: assess_trip, country_briefing, country_tourism_profile, explain_silence, get_trip_updates_since, list_events and 2 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is Travel Trends MCP working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 91 of 91 checks got a reply (100.0%), average response time 101 ms. The bar chart above shows every period we have measured.
How do I connect Travel Trends MCP?
Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does Travel Trends MCP need an API key?
No. Travel Trends MCP completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 8 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is Travel Trends MCP?
It answers our handshake in 101 ms on average, which is faster than 83% of all working MCP servers we measure. That puts it in the quick quarter of the ecosystem. The comparison comes from our own checks across the whole registry, every 15 minutes.