travel-trends-mcp

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

Beyond the annotations, it discloses output semantics, error cases, degraded-resolution behavior, blind spots, non-fabrication guarantees, localization fallbacks, and persona projection limits. The annotations cover read-only/idempotent safety, while the description adds rich operational context; openWorldHint=false is not contradicted because monitoring is limited to a declared closed set of countries and sources.

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 purpose is front-loaded and the long description is organized into readable sections. However, it is heavily over-specified with response-field implementation details, legacy-field notes, and repeated caveats that could be trimmed for a tool-selection 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?

For a complex tool with no output schema, the description explains return structure, status enums, confidence caveats, sources checked, error responses, regional scope, legs, localization, and audience behavior. It is complete enough for an agent to invoke the tool correctly and interpret its output.

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 the description carries full parameter burden and does so thoroughly: destination formats, ISO2 codes, non-EU countries, natural-language resolution, date format, optional legs structure and modes, lang behavior, and audience values. It adds substantial meaning far 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?

States a specific verb and resource: assessing one trip's current disruption status for its destinations and dates. It clearly distinguishes this from raw event-list tools by saying it returns a Decision-Support answer, not raw data.

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 to use it when the user asks whether a specific trip is affected by strikes, weather, transport disruptions, or other travel risks. It also routes continued monitoring to watch_trip via suggested_next_call, but does not explicitly contrast with country_briefing or list_events.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: full return-field semantics including the disclosed relevance floor, blind spots where silence is explicitly NOT a guarantee, and error behavior for unknown vs malformed ids. This is exactly the extra context annotations cannot convey.

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 purpose and trigger are front-loaded and waste nothing, but the remainder is a dense run-on enumerating return fields with inline brace notation and parentheticals nested three levels deep. Since no output schema exists the content is justified, yet the structure is hard to scan.

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 takes on the full burden of describing returns and does so across all four response sections plus per-destination source lists. Combined with the error cases and the `since` scoping note, an agent has everything needed to call it and interpret the result.

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 the description must carry the load — it explains that `since` "optionally scopes the recheck window" and that trip_id is regex-validated with distinct not_found and invalid_trip_id errors. It stops short of giving the actual regex or the timestamp format for `since`, so a 4 rather than a 5.

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 a specific verb and object ("Explain why a watched trip has produced no updates") that is unmistakably distinct from siblings like get_trip_updates_since (which returns updates) and assess_trip (which assesses risk). An agent can route on the first sentence alone.

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?

Gives an explicit trigger: "Use this tool when the user asks why they have not heard anything about a watched trip." It also clarifies the relationship to assess_trip (same recency input), but never states when NOT to use it or which sibling to prefer when the user wants actual updates rather than silence.

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?

Annotations declare non-idempotent, non-read-only, open-world, but the description explains WHY: no dedupe on identity, deliberate, so trips cannot be guessed. It further discloses the owner_token as a non-recoverable private key, HMAC-signed webhook delivery with a one-time notify.secret, the 5-failure auto-disable, and rejection of private-network URLs — none of which is in 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?

Front-loaded with purpose and the assess_trip handoff, then organized into labelled blocks (CREATE vs REFRESH, Args, Returns, then lang/audience/webhook/legs). It is long and the localization paragraph restates assess_trip's `localized` block at some length, but every section maps to a caller decision, so the density is justified rather than padded.

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 exists, yet the description documents the return shape ({trip_id, assessment, created_at}), the additional notify.secret, the resolved list inside the assessment, and the full error vocabulary (unknown_country, unknown_destination, invalid_webhook_url). For a 10-parameter mutation tool with a side-effecting webhook, nothing an agent needs to call it correctly is missing.

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% across 10 parameters, so the description carries the full burden and does: destinations (ISO2 plus IATA/city resolution and the EL/UK/GB/CH edge cases), date formats, label, lang, audience with its four allowed values, notify_webhook_url constraints, legs semantics, and trip_id+owner_token pairing. Error contracts for unresolvable and unmonitored codes ('we reject not guess') are spelled out.

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 a specific verb and resource ('Start monitoring one trip for disruption changes over time') and immediately distinguishes the scope from the sibling: ongoing monitoring vs. a one-off answer. An agent can tell this apart from assess_trip without opening either schema.

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 when-to-use ('ongoing monitoring ... rather than a one-off assessment'), names the alternative ('for a one-off answer, use assess_trip'), and adds a detailed CREATE vs REFRESH rule that tells the agent exactly how to avoid duplicating trips. It also states there is no stop call and that monitoring self-expires the day after date_to.

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.