travel-trends-mcp
Server Details
European tourism & travel-disruption MCP: trip risk, live events, Eurostat panels, RO county data.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 8 of 8 tools scored.
Most tools have distinct purposes (e.g., assess_trip vs. watch_trip vs. whats_changed), but some overlap exists between get_trip_updates_since and whats_changed, and between assess_trip and watch_trip, which could cause slight confusion.
Tools mostly follow a verb_noun pattern, but 'country_briefing' and 'country_tourism_profile' are noun_noun, and 'whats_changed' uses a contraction, breaking consistency.
With 8 tools, the server is well-scoped for travel disruption monitoring; each tool serves a clear purpose without being excessive or lacking.
The tool set covers core workflows (trip assessment, monitoring, updates, events, country info), though a tool to manage watched trips (e.g., stop watching) is absent.
Available Tools
8 toolsassess_tripARead-onlyIdempotentInspect
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).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ||
| date_to | Yes | ||
| audience | No | ||
| date_from | Yes | ||
| destinations | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behavioral traits: omits sub-floor noise, treats calm as monitoring result (not forecast), rejects invalid inputs with explicit errors, never fabricates data. Annotations confirm readOnlyHint and non-destructive behavior, and description aligns perfectly (no contradiction). Discloses localization and audience behaviors, including translation caveats and fallbacks.
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 very long and detailed, with every sentence adding value for a complex tool. It is front-loaded with the core purpose. However, it could be slightly more concise by grouping some technical details, though the thoroughness is justified given the tool's complexity.
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?
Despite having no output schema, the description fully describes the response structure (MCP-facing blocks, localization, audience persona, track_record_ref, suggested_next_call). It covers input, output, error handling, limitations (blind spots), and behavioral nuances. For a 5-parameter tool with no output schema, the description is exceptionally complete.
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 input schema has 0% description coverage, so the description carries full burden. It explains each parameter: date_from/date_to format, destinations accepted formats (ISO2, IATA, cities) with resolution process, lang for localization, audience for role-specific actions. Provides details on defaults, validation, and behavior for each parameter, fully compensating for schema lack.
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: 'Decision support for ONE trip: "should I care?", answered honestly.' It specifies the action (assess), resource (trip), and scope (single trip with destinations and dates). It distinguishes from siblings like 'list_events' and 'watch_trip' by focusing on a single trip decision-support answer rather than raw events or ongoing monitoring.
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 explicit input requirements: destinations (EU-27 ISO2 codes, specific non-EU27 countries, IATA codes, city names), date_from, date_to, and optional lang and audience. It explains input validation and error handling. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., vs. list_events for raw events), though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
country_briefingARead-onlyIdempotentInspect
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"}``.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant context beyond annotations: specifies return payload structure (headline counts, monitoring coverage, backtest trust, caveats), error case ('unavailable'), and scope limitations of the country parameter, all while annotations indicate read-only, idempotent, non-destructive behavior.
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?
Description is well-structured with a clear first sentence stating purpose. While it includes thorough details, each sentence adds value, and it avoids unnecessary fluff.
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?
For a tool with a single optional parameter and no output schema, the description covers all relevant aspects: payload content, error handling, parameter behavior, and caveats, making it fully complete for an AI agent.
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?
Despite 0% schema coverage, the description fully compensates by explaining the 'country' parameter: EU-27 ISO2 alpha-2 format with example 'EL' for Greece, and clarifies that it only filters events while other metrics remain EU-wide.
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?
Description clearly states the tool retrieves 'today's published daily briefing, pre-formatted for end users,' with specific details on the payload. It distinguishes from sibling tools like 'list_events' or 'assess_trip' by focusing on a briefing artifact.
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?
No explicit guidance on when to use this tool versus alternatives like 'list_events' or 'assess_trip'. It does describe the effect of the optional 'country' parameter, implying usage context for filtering events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
country_tourism_profileARead-onlyIdempotentInspect
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"}.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it explains data sourcing (public dataset, no estimation), error responses for unknown countries or missing artifacts, and includes links to raw data. Annotations (readOnlyHint, idempotentHint) are consistent and the description enhances transparency.
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 moderately lengthy but well-structured: it front-loads the purpose and then lists the data components. Every sentence provides specific value, though some redundancy (e.g., 'pure projection') could be trimmed.
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?
With no output schema, the description fully explains the return values: yearly nights/arrivals totals, average stay, seasonality, competitiveness insights, and error formats. It covers what the tool returns in detail.
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?
Schema coverage is 0% for the only parameter 'code', but the description explains it is an EU-27 ISO2 code with an example (Greece = 'EL'), adding meaning beyond the bare schema definition.
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 it provides a tourism profile for one EU-27 country using Eurostat data, listing specific metrics. It distinguishes from sibling tools like country_briefing or assess_trip by focusing solely on tourism statistics.
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 does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or usage context beyond its function. It lacks comparative guidance against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_silenceARead-onlyIdempotentInspect
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"}.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | ||
| trip_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses error handling for unknown/malformed trip_id, the structure of the response, and the non-coverage of blind spots. This adds significant value beyond annotations, which only indicate readOnly and idempotent hints.
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 front-loaded with purpose and packed with information, but the metaphorical 'SILENCE AUDIT' phrase may be slightly less direct. Still, every sentence contributes, and it is efficient for the detail provided.
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?
Despite no output schema, the description explains response fields (recheck_count, suppressed, blind_spots) and error behavior. Minor gaps: suppressed subfields are partially defined, and since format is unspecified. Overall thorough.
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?
With 0% schema coverage, the description adds meaning: trip_id is regex-validated and errors are described; since scopes the recheck window. However, it does not specify the format for since or the full allowed types, partially compensating.
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 answers 'why didn't I hear from you?' for a watched trip, using specific fields like recheck_count, suppressed, and blind_spots. It distinguishes itself from stateless models and implies use for silence auditing.
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 implies usage when a user wonders why no updates were received, but it does not explicitly contrast with sibling tools like get_trip_updates_since or list_events. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trip_updates_sinceARead-onlyIdempotentInspect
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"}.
| Name | Required | Description | Default |
|---|---|---|---|
| since | Yes | ||
| trip_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: describes return format, error cases ('not_found', 'invalid_trip_id'), regex validation for trip_id, and empty `since` behavior. Annotations already indicate read-only and non-destructive, but description enriches.
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?
Front-loaded with main purpose, then details. Three paragraphs, but each sentence adds value. Slightly verbose on error cases, but still efficient.
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?
No output schema, but description lists return fields (trip_id, since, new_update_count, updates) and error responses. Covers validation, empty `since`, and ordering (oldest-first). Adequate for the tool's complexity.
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?
Schema description coverage is 0%, so description must compensate. It mentions `since` as ISO-8601 and trip_id as regex-validated, but does not fully describe parameters (e.g., no format for `since` beyond wording, no details for trip_id pattern). Minimal added value.
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 it returns trip updates after a `since` timestamp, with a specific verb and resource. It distinguishes itself from siblings like 'assess_trip' and 'country_briefing' by focusing on updates.
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?
Explicitly says 'Use this to push only what is new since the user last looked' and explains behavior for empty `since`. However, it does not provide when NOT to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_eventsARead-onlyIdempotentInspect
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"}.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | ||
| status | No | ||
| country | No | ||
| min_severity | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds valuable context beyond annotations: events are deterministic, rule-based, and thresholds are disclosed in records. Also notes the return structure and error case. No contradictions.
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?
Very concise: three sentences covering purpose, behavior, filters, and return format. Front-loaded with core purpose. No redundant words.
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 no output schema, the description specifies return format ({count, events, filters}) and error case. All key aspects (purpose, filters, behavioral traits, error handling) are addressed, making it complete for a list tool.
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?
Schema has 0% description coverage, but the description fully compensates by explaining each filter: status, country (with ISO2 example), domain (with examples), and min_severity (with ordered scale). This adds significant meaning beyond raw 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?
States exactly what the tool does: 'List detected travel-disruption events for EU-27 tourism.' Specifies domain (EU-27), nature (deterministic, rule-based), and available filters. Clearly distinguishes from sibling tools which focus on individual trips or briefings.
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?
Describes the tool's functionality and filters, implying use when needing broad event lists. However, it does not explicitly mention when to use this tool over alternatives like assess_trip or country_briefing, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_tripAInspect
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"}.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ||
| label | No | ||
| date_to | Yes | ||
| audience | No | ||
| date_from | Yes | ||
| destinations | Yes | ||
| notify_webhook_url | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims idempotency ('Idempotent on identity... re-watching the same destinations+window refreshes the same trip'), but annotations set idempotentHint=false, creating a direct contradiction. Beyond this, the description provides extensive behavioral details (webhook, localization, error handling), but the contradiction is a critical flaw per guidelines.
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 verbose and includes many details; while valuable, it could be better structured with a summary of key points first. The front-loading of the main purpose is good, but the length may reduce scanability.
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 (7 params, no output schema, no parameter descriptions in schema), the description is very complete. It covers input validation, behavior (idempotency, material changes), webhook delivery, localization, error responses, and return structure. No output schema exists, but the description explains return values adequately.
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?
Schema description coverage is 0%, so the description must explain all parameters. It thoroughly covers destinations (ISO2, IATA, city names with resolution rules), date_from/date_to format, lang, audience, notify_webhook_url with validation. Each parameter gets meaningful context beyond the schema properties.
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: 'Watch a trip over time — the continuity primitive a chat cannot match.' It contrasts with one-time assessments and lists specific resources: persisted monitored object, initial assessment, stable trip_id. Distinguishes from siblings like assess_trip (one-time) and get_trip_updates_since (retrieval).
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 explains when to use: for continuous monitoring over time, idempotent re-watching, and material change updates. It implies alternatives (e.g., assess_trip for one-shot) but does not explicitly list when not to use. The context is clear for the typical use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whats_changedARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | ||
| trip_id | Yes | ||
| audience | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is safe and idempotent. The description adds valuable context: return fields (material, summary, delta events, etc.), error handling for invalid/malformed IDs, material vs non-material changes, forwarding of moat blocks, and audience parameter behavior. It does not contradict 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 front-loaded with the core purpose and uses paragraphs for clarity. It is somewhat lengthy but each sentence adds value. Minor fluff could be trimmed, but overall it is well-structured.
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 no output schema, the description thoroughly explains the return structure, including fields for both material and non-material changes, error responses, and forwarded moat blocks. It covers edge cases (e.g., legacy code paths) and audience persona blocks. Completeness is high for a complex delta tool.
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?
Schema description coverage is 0%, so the description must fully explain parameters. It does: 'since' is optional ISO-8601 timestamp, 'audience' is optional with valid values listed (tmc, hotel, etc.), and 'trip_id' is regex-validated. This adds significant meaning beyond the raw 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: 'What changed for a watched trip since last time — ONLY the delta.' It specifies it recomputes the trip's current assessment and diffs against a checkpoint. This distinguishes it from siblings like 'assess_trip' (full assessment) and 'get_trip_updates_since' (list of updates).
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 mentions 'The continuity payload a memoryless chat cannot produce' implying usage for delta tracking. However, it does not explicitly state when not to use this tool versus alternatives, nor does it mention prerequisites (e.g., trip must be watched). Some context is provided, but explicit guidance is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!