travel-trends-mcp

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnly, idempotent), the description discloses error behavior ('Invalid inputs return an explicit {"error": ...}; nothing is fabricated'), blind spots (Switzerland key-pending), and translation honesty ('never a fake translation'). No contradiction with 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 verbose but well-structured with bullet points and front-loaded with a clear summary. Each section covers a meaningful aspect (usage, parameters, output structure, localization, audience). However, some caveats (e.g., 'never a false all-clear') are repeated, and the length is borderline for an MCP description.

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 lacking an output schema, the description thoroughly details the response structure (presentation block, track_record_ref, suggested_next_call, resolved, localized, persona) and error handling, making it complete for an agent to consume.

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 fully compensates: it details destination formats (EU-27 ISO2 codes, IATA, city names), date format (YYYY-MM-DD), language codes, and audience values, plus error handling for unknown tokens.

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 first sentence precisely defines the tool's scope: 'Assess one trip: current disruption status for its destinations and dates.' This distinguishes it from sibling tools like country_briefing (country-level) or watch_trip (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 explicitly states 'Use this tool when the user asks whether a specific trip is affected by strikes, weather, transport disruptions or other travel risks.' It also mentions a follow-up tool (watch_trip) for continued monitoring and frames the output as decision-support rather than raw data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only, idempotent, non-destructive annotations, the description discloses critical behaviors: the payload structure (headline counts, plain-language headlines, monitoring coverage, trust figures, caveats), the requirement to always relay caveats, the country filtering scope (narrows events only, not metrics), and the exact error response for a missing artifact. This is rich, transparent context.

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 dense but every sentence earns its place. It front-loads the core purpose, then adds usage guidance, return payload details, a critical caveat-relaying instruction, parameter semantics, and an error case. No filler or redundancy; structure is logical and scannable.

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?

There is no output schema, so the description must explain return values—it does so explicitly, including the key components and the caveats list. It also covers the only parameter, the error condition, and the global vs. country-wide scope nuance. For a tool with one optional parameter and no output schema, this is fully 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?

Schema provides almost no param description (0% coverage), so the description carries the full burden. It explains the optional country parameter with format (EU-27 ISO2 alpha-2), gives an example (Greece = "EL"), and precisely describes the behavioral effect (narrows events list only; headline_counts/monitoring/trust stay EU-27-wide). This is exemplary parameter documentation.

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 starts with a specific verb 'Get' and identifies the exact resource: 'today's published daily briefing, pre-formatted for end users.' It also distinguishes itself from trip-specific tools by stating it is 'not tied to one specific trip,' directly addressing the sibling context.

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 states when to use this tool: 'for a general "what is happening today in EU travel" question that is not tied to one specific trip.' It implicitly excludes trip-specific scenarios but does not name alternative tools explicitly. The clear context and exclusion provide strong guidance, falling just short of naming specific alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint, idempotentHint), the description adds critical behavior: it is a 'pure projection of the published artifacts,' discloses that 'every number is computed from the same public dataset,' provides error formats for unknown country ('unknown_country') and missing artifact ('unavailable'), and notes that links carry citable pages plus raw JSON. This is rich contextualization with no contradiction.

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 information-dense yet each sentence earns its place: purpose, usage guideline, data source, metric list, parameter format, and error handling. It is front-loaded with the primary function and contains no filler or tautology.

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 there is no output schema, the description enumerates all return aspects: YoY totals, average stay, seasonality with peak-to-mean ratio, visitor share, recovery vs 2019, growth vs EU average, and competitiveness insights. It also documents data provenance, error cases, and link details, making it self-sufficient for the 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?

With schema description coverage at 0%, the description fully compensates by explaining that `code` is an EU-27 ISO2 code and gives the concrete example 'Greece = "EL"'. It also clarifies behavior for invalid or missing artifacts, which helps the agent invoke the tool correctly.

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 opens with 'Tourism profile for one EU-27 country — a decade of Eurostat data,' which is a specific verb+resource statement. It also explicitly differentiates from siblings by saying 'Use this tool for questions about a country's tourism statistics, seasonality or visitor mix, not for live disruptions,' making its scope unmistakable.

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?

It clearly states when to use the tool (for tourism statistics, seasonality, visitor mix) and when not to use it (not for live disruptions). However, it does not name alternative tools for live disruptions, though the sibling list includes candidates like list_events, so the guidance is not fully explicit on alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds substantial behavioral detail: it explains return fields (recheck_count, suppressed, confidence, blind_spots), gives a concrete example of the relevance floor, and discloses that silence is not a guarantee for certain domains (e.g., aviation-IT). It also specifies error responses for unknown/malformed trip IDs. This goes far beyond the 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 longer than average, but every sentence adds value, including return structure, examples, and edge cases. It is front-loaded with the core purpose, then details. There is no fluff, though a reader might need to absorb a lot; this density is justified by 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?

With no output schema, the description fully carries the burden of explaining returns. It lists all key output fields, provides an illustrative example, explains blind spots, and documents error cases. This is complete enough for an agent to understand the tool's behavior, limitations, and expected outputs without additional context.

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 compensate. It does: `since` is explained as optionally scoping the recheck window, and trip_id is described as regex-validated with specific error behaviors. While the exact query format for `since` is not given, the description provides meaningful semantics beyond the raw schema types.

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 opens with a specific, action-oriented statement: 'Explain why a watched trip has produced no updates.' It clearly identifies the resource (watched trip) and the action (explain silence), distinguishing 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?

Explicitly states when to use: 'Use this tool when the user asks why they have not heard anything about a watched trip.' While it doesn't explicitly name alternatives or when-not-to-use, the context is clear and the wording differentiates it from tools that fetch updates or manage watchlists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses significant behavioral details beyond the annotations: returns entries 'strictly after the `since` timestamp, oldest-first', describes the response shape, and specifies error behaviors for unknown and malformed IDs. Annotations already declare read-only and idempotent, and the description adds 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 well-structured and concise, leading with the core purpose and then covering notable behaviors and edge cases in a compact, readable form. 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?

Even though there is no output schema, the description explicitly states the return object ({trip_id, since, new_update_count, updates}), error responses, and validation rules. Combined with the detailed parameter semantics and usage guidance, the description is fully self-contained 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?

The schema provides no descriptions, but the description fully compensates: it defines `since` as 'ISO-8601 timestamp (the user's last-seen time)' and the empty-since behavior, and specifies the `trip_id` format via regex and associated error messages.

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: 'The watched-trip updates log filtered to entries AFTER `since`.' It specifies the resource (trip updates log) and the action (fetch filtered by since), and explicitly distinguishes from the sibling tool whats_changed, which provides a live recomputed diff.

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 usage direction: 'Use this tool to fetch the stored update entries the user has not seen yet; for a live recomputed diff, use whats_changed instead.' This states when to use and points to the alternative. It also covers edge cases for empty `since` and validation errors.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive. The description adds meaningful behavioral context: events are deterministic rule-based detections, thresholds are disclosed in each record, nothing is model-generated, and missing index yields a specific error format. This goes well beyond the 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?

Four dense sentences with zero filler. The first sentence states purpose, the second provides usage guidance, the third explains data provenance, and the fourth covers filters and return format. Every sentence adds value and is well-organized.

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 specifies the return shape ({count, events, filters}) and the error case. It covers all parameters, the underlying data source, and filters. For a list tool with this complexity, the description is complete and leaves no significant 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 has 0% description coverage and no enums, so the description carries the full burden. It clearly explains each filter: status with examples, country as EU-27 ISO2 (Greece = 'EL'), domain with examples, and min_severity with an explicitly ordered scale (info < watch < warning < severe). This is exactly the missing parameter semantics.

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 opens with a specific verb+resource+scope: 'List detected travel-disruption events for EU-27 tourism.' It clearly distinguishes from siblings by positioning this as the browse/filter tool and explicitly directing trip-specific questions to assess_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?

Explicit usage guidance: use for browsing/filtering across countries, and 'for a question about one specific trip, use assess_trip.' This directly tells the agent when to prefer an alternative, satisfying the when-to-use and when-not-to-use criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses substantial behavior beyond annotations: idempotency on identity, updates only on material changes, webhook secret shown once, delivery failure disabling, and specific error responses. This complements annotations like idempotentHint and readOnlyHint without contradiction.

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?

Though long, the description is meticulously structured, front-loading the core action and then systematically covering parameters, localization, audience, and webhook delivery. Every sentence carries essential information; there is no filler or 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 tool's complexity and lack of output schema, the description fully covers return values, error handling, idempotency, webhook security, and localization behavior. It provides a complete mental model for correct invocation and expected outcomes.

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 compensates fully by explaining every parameter: destinations with IATA/city resolution, date format, optional label, lang, audience, and notify_webhook_url requirements. It even details edge cases like unknown_country and unknown_destination errors.

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 opens with a specific verb and resource: 'Start monitoring one trip for disruption changes over time.' It clearly distinguishes from assess_trip by contrasting ongoing monitoring versus one-off assessment, making the purpose unmistakable.

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?

Explicit guidance is provided: 'Use this tool when the user wants ongoing monitoring... for a one-off answer, use assess_trip.' It also clarifies idempotency behavior and webhook re-watch semantics, giving clear when-to-use and when-not-to-use scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds substantial behavioral context: recomputation and diffing, non-material ticks with 'never invented churn', error responses for unknown/malformed IDs, forwarded presentation blocks with 'never fabricated' caveats, and honest errors for unknown audiences. No contradictions with 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 longer than average, but it is front-loaded with the core purpose and each paragraph adds necessary details about return values, errors, forwarded context, and audience behavior. It could be tightened slightly, as some return-field details are repeated across paragraphs, but overall it is well structured and information-dense.

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 and three parameters, the description is exceptionally complete: it covers the return object shape, material/non-material branches, error semantics, optional parameters, alternative tools, and edge-case behavior. It leaves little ambiguity for an agent selecting and invoking the 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 carries the full burden for explaining parameters. It explains trip_id via regex validation and error cases, since as an optional ISO-8601 timestamp used as the checkpoint, and audience as an optional tmc/hotel/ota/tour_operator value with defined behavior. This goes well beyond the bare 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 opens with a specific verb and resource: 'Report only what changed for a watched trip since a checkpoint.' This precisely defines the tool's scope and clearly differentiates it from siblings, even naming get_trip_updates_since as the alternative for stored notification logs.

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?

Explicit usage guidance is provided: '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.' This states both when to use and when not to use the tool, naming a specific alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.