eu. mmatinca/ travel-trends-mcp
by mmatinca.eu · remote · no sign-in to list tools · v0.3.1 · published by eu.mmatinca
European tourism & travel-disruption MCP: trip risk, live events, Eurostat panels, RO county data.
8 tools: 4 change things and 4 only read.
Scanned Oct 21, 2026
- Deletes or cancels0Claude Code: deny
- Can't be undone0Claude Code: ask
- Changes things4Claude Code: ask: see these tools
- Only reads4Claude Code: allow: see these tools
3 checks matched something in the tool definitions. No finding is not a safety guarantee. How the checks work.
claude mcp add --transport http travel-trends https://travel-trends.mmatinca.eu/mcp/v1Findings
Matches of fixed checks, with the text they matched.
The server marks "country_tourism_profile" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
What this check looks forMatched text
annotations: {"readOnlyHint":true,"destructiveHint":false,"idempotentHint":true,"openWorldHint":false}; The input takes a statement or command to run (input.code), which can change anything it can reach.
- Infoassess_trip
The description is 5,230 characters long, over the 2,000 this check looks for.
What this check looks forMatched text
description ends: "...set, never guessed. Omit `audience` for the default (no persona block)."
- Infowatch_trip
The description is 3,763 characters long, over the 2,000 this check looks for.
What this check looks forMatched text
description ends: "...private-network URLs are rejected with {"error": "invalid_webhook_url"}."
Tools
Open a tool for its reasons and full description. Descriptions are the publisher's own words, shown as they are.
8 tools
Changes things 4Claude Code: ask
assess_tripAssess one trip: current disruption status for its destinations and dates.1 finding
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Findings
- Info
The description is 5,230 characters long, over the 2,000 this check looks for.
What this check looks forMatched text
description ends: "...set, never guessed. Omit `audience` for the default (no persona block)."
Description, as the server wrote it Assess one trip: current disruption status for its destinations and dates. Use this tool when the user asks whether a specific trip is affected by strikes, weather, transport disruptions or other travel risks. 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: {tool, context} — the suggested follow-up (watch_trip) when the user wants continued monitoring. 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 — useful for a 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).
Annotations the server declares
- readOnlyHint: true
- destructiveHint: false
- idempotentHint: true
- openWorldHint: false
country_tourism_profileTourism profile for one EU-27 country — a decade of Eurostat data.1 finding
Why it is in this group
- The input takes a statement or command to run (input.code), which can change anything it can reach.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Findings
- Warn
The server marks "country_tourism_profile" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
What this check looks forMatched text
annotations: {"readOnlyHint":true,"destructiveHint":false,"idempotentHint":true,"openWorldHint":false}; The input takes a statement or command to run (input.code), which can change anything it can reach.
Description, as the server wrote it Tourism profile for one EU-27 country — a decade of Eurostat data. Use this tool for questions about a country's tourism statistics, seasonality or visitor mix, not for live disruptions. 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"}.
Annotations the server declares
- readOnlyHint: true
- destructiveHint: false
- idempotentHint: true
- openWorldHint: false
watch_tripStart monitoring one trip for disruption changes over time.1 finding
Why it is in this group
- The description's first verb is "start": a word for a change.
Findings
- Info
The description is 3,763 characters long, over the 2,000 this check looks for.
What this check looks forMatched text
description ends: "...private-network URLs are rejected with {"error": "invalid_webhook_url"}."
Description, as the server wrote it Start monitoring one trip for disruption changes over time. Use this tool when the user wants ongoing monitoring of a trip rather than a one-off assessment (for a one-off answer, use assess_trip). Persists the trip as a monitored object and returns its initial assessment plus a random, unguessable trip_id AND a one-time `owner.owner_token`. Store BOTH: the trip_id is the (public, shareable) URL handle, the owner_token is the private key needed to change or stop the trip later. CREATE vs REFRESH: called with just destinations+dates it CREATES a new trip every time (it does NOT dedupe on identity — that is deliberate, so nobody can reach your trip by guessing your itinerary). To update an existing trip (change its label or webhook), call again passing BOTH its `trip_id` and `owner_token`; a missing/wrong token is rejected. Each pipeline run then 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. To change or remove the webhook later, re-call with the trip_id + owner_token and the new notify_webhook_url (or "" to remove 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"}.
Annotations the server declares
- readOnlyHint: false
- destructiveHint: false
- idempotentHint: false
- openWorldHint: true
whats_changedReport only what changed for a watched trip since a checkpoint.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it Report only what changed for a watched trip since a checkpoint. Use this tool when the user asks for news on a trip already registered with watch_trip; for the stored notification log rather than a live diff, use get_trip_updates_since. 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 presentation 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 (the suggested follow-up action). 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.
Annotations the server declares
- readOnlyHint: true
- destructiveHint: false
- idempotentHint: true
- openWorldHint: false
Only reads 4Claude Code: allow
country_briefingGet today's published daily briefing, pre-formatted for end users.No findings
Why it is in this group
- The description's first verb is "get": a word for reading.
Description, as the server wrote it Get today's published daily briefing, pre-formatted for end users. Use this tool for a general "what is happening today in EU travel" question that is not tied to one specific trip. 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"}``.
Annotations the server declares
- readOnlyHint: true
- destructiveHint: false
- idempotentHint: true
- openWorldHint: false
explain_silenceExplain why a watched trip has produced no updates.No findings
Why it is in this group
- The name "explain_silence" says "explain": a word for reading.
Description, as the server wrote it Explain why a watched trip has produced no updates. Use this tool when the user asks why they have not heard anything about a watched trip. Returns {recheck_count, last_checked} (proof the trip was actively monitored), {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"}.
Annotations the server declares
- readOnlyHint: true
- destructiveHint: false
- idempotentHint: true
- openWorldHint: false
get_trip_updates_sinceThe watched-trip updates log filtered to entries AFTER `since`.No findings
Why it is in this group
- The name "get_trip_updates_since" says "get": a word for reading.
Description, as the server wrote it 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 tool to fetch the stored update entries the user has not seen yet; for a live recomputed diff, use whats_changed instead. 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"}.
Annotations the server declares
- readOnlyHint: true
- destructiveHint: false
- idempotentHint: true
- openWorldHint: false
list_eventsList detected travel-disruption events for EU-27 tourism.No findings
Why it is in this group
- The name "list_events" says "list": a word for reading.
Description, as the server wrote it List detected travel-disruption events for EU-27 tourism. Use this tool to browse or filter current disruption events across countries; for a question about one specific trip, use assess_trip. 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"}.
Annotations the server declares
- readOnlyHint: true
- destructiveHint: false
- idempotentHint: true
- openWorldHint: false
This is not a safety rating, and no finding is not a safety guarantee. The groups and findings come from fixed checks of the tool definitions the server returned on the date shown, not from its code or what it does when called. How the checks work.
Install
Pinned to version 0.3.1. Values in angle brackets are yours to fill in.
claude mcp add --transport http travel-trends https://travel-trends.mmatinca.eu/mcp/v1Run in a terminal.
Claude Code permissions
Allow the reads, ask before a change, deny the deletes. Paste into .claude/settings.json.
{
"permissions": {
"allow": [
"mcp__travel-trends__explain_silence",
"mcp__travel-trends__get_trip_updates_since",
"mcp__travel-trends__country_briefing",
"mcp__travel-trends__list_events"
],
"ask": [
"mcp__travel-trends__assess_trip",
"mcp__travel-trends__watch_trip",
"mcp__travel-trends__whats_changed",
"mcp__travel-trends__country_tourism_profile"
],
"deny": []
}
}Tools that only read are allowed, tools that change things ask first, tools that delete or cancel are denied. It assumes the server is installed as travel-trends. Review it before you use it.