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.7/5 across 8 of 8 tools scored.
Each tool has a clear, distinct purpose: assess_trip for one-off decision support, watch_trip to create persistent monitoring, get_trip_updates_since for log retrieval, whats_changed for delta comparison, explain_silence for calm period audits, list_events for event browsing, country_briefing for daily summaries, and country_tourism_profile for tourism statistics. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., assess_trip, list_events, watch_trip). Even 'whats_changed' fits as a colloquial verb phrase. No mixing of conventions or vague verbs.
With 8 tools, the server is well-scoped for its purpose of travel disruption monitoring and tourism data. Each tool serves a distinct need without bloat, and the count is appropriate for both simplicity and coverage.
The tool set covers core workflows: creating and monitoring trips, retrieving updates and deltas, auditing silent periods, listing events, and accessing briefings/profiles. A minor gap is the absence of a tool to list all watched trips, but the set is otherwise comprehensive for the intended domain.
Available Tools
8 toolsassess_tripAInspect
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?
With no annotations, the description fully discloses behavior: it is honest, never fabricates, omits sub-floor noise, handles blind spots (e.g., Switzerland key-pending), returns explicit errors, and details the response structure including localization and persona blocks. Every behavioral trait is transparently described.
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 extremely long and detailed, covering many edge cases and response structure. While thorough, it lacks conciseness; an agent might struggle to parse quickly. The first sentence front-loads the purpose, but the density reduces readability.
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 comprehensively covers input, processing, output structure, error cases, localization, and audience-specific actions. It leaves no obvious gap for a complex decision-support 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 coverage is 0%, but the description thoroughly explains each parameter: destinations (types, resolution), dates (format), lang (examples, default), and audience (valid values, effect). It adds critical meaning beyond the schema's bare type definitions.
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 explicitly states it provides 'Decision support for ONE trip: "should I care?", answered honestly.' It uses specific verbs and resources, clearly distinguishing from siblings like country_briefing or list_events by focusing on trip-specific disruption assessment with destinations and date ranges.
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 clear input requirements (destinations, date_from, date_to) and explains accepted formats (ISO2 codes, IATA, cities) with error handling. It also mentions optional parameters (lang, audience). However, it does not explicitly state when NOT to use the tool or compare it to alternatives like watch_trip.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
country_briefingAInspect
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?
With no annotations, the description fully discloses the return payload structure, the scoping behavior of 'country', the error case for missing artifacts, and an imperative to relay caveats.
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, uses minimal but informative sentences, and avoids redundancy. Every sentence adds value.
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 single optional parameter and no output schema, the description comprehensively covers functionality, return data, parameter behavior, and error handling.
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 has 0% coverage for the parameter, but the description compensates by explaining the parameter's format (ISO2 alpha-2), example value, and its scoping effect on the events list only.
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 retrieves 'today's published daily briefing' and details the payload contents. It is distinct from sibling tools like 'assess_trip' or 'list_events'.
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 the tool and the effect of the optional 'country' parameter, but does not explicitly mention when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
country_tourism_profileAInspect
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?
With no annotations, the description carries full burden. It discloses that all numbers are computed from public data, explains error responses (unknown_country, unavailable), and states the tool is a 'pure projection' with no estimation. This provides comprehensive behavioral insight.
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 well-structured with clear front-loading of purpose, detailed metrics, and error handling. Every sentence adds value without redundancy.
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 (multiple metrics), one parameter, no output schema, and no annotations, the description is remarkably complete. It explains all output fields, data source, computation methods, error types, and provides links for citation.
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 only defines 'code' as a string with 0% description coverage. The description adds meaning by specifying EU-27 ISO2 format, giving an example (Greece = 'EL'), and explaining its purpose, fully compensating for the lack of schema descriptions.
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 provides a tourism profile for one EU-27 country, listing specific metrics derived from Eurostat data. It distinguishes from sibling tools by focusing on tourism statistics rather than trip or event management.
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 when to use (for EU-27 tourism data) but does not explicitly state when not to use or provide alternatives among sibling tools. Context is clear but without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_silenceAInspect
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?
With no annotations, the description fully discloses behavior: output fields (recheck_count, suppressed, blind_spots), error handling (unknown/malformed trip_id), and limitations (blind spots). 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?
The description is front-loaded with a clear goal and then details output structure. It is somewhat lengthy but every sentence adds value; could be slightly more structured but not wasteful.
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 comprehensively covers return values, arguments, error cases, and blind spots, making the tool fully understandable.
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 adds meaning beyond the schema: explains 'since' scopes the recheck window, and trip_id is regex-validated with error responses. This compensates well.
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 answers 'why didn't I hear from you?' with a 'SILENCE AUDIT', specifying the exact output structure. This unique function distinguishes it from sibling tools like 'get_trip_updates_since' or 'watch_trip'.
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 use when a user wonders about missing updates, and contrasts with a 'stateless model'. However, it lacks explicit guidance on when not to use this tool or alternatives among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trip_updates_sinceAInspect
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?
No annotations provided, but the description explains return format, empty since behavior, and error responses. It covers validation and expected outputs, though it doesn't mention whether the operation is read-only or any side effects.
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?
Two short paragraphs, first sentence front-loads the purpose. Every sentence adds value without redundancy. No fluff, highly 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?
Given the tool's simplicity (2 params, no output schema), the description is fully adequate. It covers input validation, output structure, edge cases (empty since), and errors. No gaps remain for effective use.
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%, but the description adds crucial detail: 'since' is ISO-8601 timestamp, 'trip_id' is regex-validated. It explains meaning and behavior of empty 'since', significantly compensating for the missing schema descriptions.
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 retrieves trip updates after a given timestamp, with specific verb 'get' and resource 'trip updates since'. It distinguishes from siblings by focusing on incremental updates, unlike list_events or whats_changed.
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 gives a clear use case: 'push only what is new since the user last looked'. It explains empty since behavior and error handling. However, it doesn't explicitly compare with alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_eventsAInspect
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?
In the absence of annotations, the description fully discloses behavioral traits: events are deterministic, rule-based, thresholds are disclosed, nothing model-generated. It also specifies return format ({count, events, filters}) and error behavior (returns 'unavailable' on missing index).
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 efficiently structured: one sentence for purpose, one for behavior and data source, one for filters, one for return format. No wasted words, information is front-loaded and each sentence adds unique value.
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 4 optional parameters, no output schema, and no annotations, the description is remarkably complete. It covers purpose, data source, deterministic nature, filter options with examples, return structure, and error handling. No significant gaps remain for agent understanding.
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 description coverage, the description adds significant meaning by listing all parameters, providing examples (e.g., status 'active'/'resolved', country 'EL' for Greece, domain 'weather'/'aviation', min_severity scale info < watch < warning < severe), fully compensating for the schema's lack of descriptions.
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 lists detected travel-disruption events for EU-27 tourism, a specific verb and resource. It distinguishes the scope (EU-27 tourism) and provides unique context not present in sibling tool names like 'assess_trip' or 'country_briefing'.
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 lists available filters (status, country, domain, min_severity) and implies usage for querying events with those filters, but does not provide explicit guidance on when to use this tool versus alternatives or any when-not scenarios.
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?
With no annotations, the description carries full burden. It discloses all behavioral traits: idempotent on identity, only updates on material changes (never on calm tick), webhook delivery with HMAC-SHA256 signature, secret shown once, webhook disable after 5 consecutive failures, destination resolution logic, localization's 'honest reassurance' and never dropping caveats, audience-specific actions. Error responses are explicitly documented.
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 well-structured with clear paragraphs and bullet-like lists. It is front-loaded with the main purpose and then covers details. While it is quite long, every sentence adds value. Minor verbosity in some sections (e.g., elaborate destination resolution) but overall effective.
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 parameters, no output schema), the description is remarkably complete. It covers all inputs, return format (trip_id, assessment, created_at), error handling for unknown countries and unresolvable tokens, webhook mechanics, localization details, audience-specific actions, and the idempotency behavior. No obvious gaps.
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 explains all 7 parameters: destinations (with allowed formats: ISO2, IATA, city names, including examples like Greece='EL', Norway='NO', etc.), date_from/date_to (YYYY-MM-DD), lang (localization), label (optional), audience (roles), notify_webhook_url (https only, removal by empty string). Constraints and behavior for each parameter are detailed, adding 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 'Watch a trip over time — the continuity primitive a chat cannot match.' It defines that the tool persists a trip as a monitored object, returns an initial assessment and stable trip_id, and updates on material changes. This distinguishes it from sibling tools like assess_trip (one-time) and get_trip_updates_since (retrieves 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 provides extensive usage guidance: idempotency (re-watching same destinations+window refreshes same trip), material change update policy, webhook notification behavior, destination resolution including error cases, localization option, audience parameter, and valid input formats. It also specifies when not to use it (e.g., unmonitored codes rejected). This covers when-to-use and what to expect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whats_changedAInspect
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?
With no annotations, the description fully discloses behavior: returns specific fields, non-material change behavior ('never invented churn'), ID validation with error responses, forwarding of moat blocks with caveats, and audience handling. Every behavioral aspect is covered.
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 thorough but verbose. However, every sentence adds value, and the main purpose is front-loaded. Could be slightly more concise, but given the complexity 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?
Despite no annotations or output schema, and 0% schema coverage, the description covers all parameters, return structure, error handling, edge cases (non-material, id validation), and optional forwarding of context. It is fully self-contained.
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%, so description compensates fully. It explains `since` as optional ISO-8601 timestamp, `trip_id` with regex pattern (^trip-[a-z0-9-]+$), and `audience` as optional with enumerated values (tmc, hotel, ota, tour_operator) plus error handling. Adds meaning beyond 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 it shows 'what changed for a watched trip since last time — ONLY the delta.' It specifies the verb (what changed) and resource (watched trip) and distinguishes it from general assessment or watching tools by emphasizing the delta and continuity payload.
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 context on when to use ('The continuity payload a memoryless chat cannot produce') and explains the optional `since` parameter (defaults to last evaluation). It does not explicitly contrast with sibling tools like get_trip_updates_since, but the unique delta focus is implied.
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!