Wizzair MCP

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

With no annotations, the description carries the full burden and does well: it discloses the live private-API source, the unofficial status, that failures can occur from rotation or throttling, an implicit cache (via no_cache), and the local-currency return shape. It omits any guidance on retry behavior or rate limits, which keeps it short of a 5.

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?

One tight paragraph, front-loaded with the core definition, then output shape, then the reliability caveat, then sibling routing. Every sentence carries information an agent needs; nothing is redundant with the schema.

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 9-parameter tool with no output schema, the description compensates by explaining the return value (one price per day, local currency, fare-finder link, return legs) and the upstream volatility. Nothing needed 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 100%, so the baseline is 3, but the description adds consequence-level meaning the schema lacks: day_interval defines an up-to-19-day window and return_date causes extra return-leg days in the output. wdc, no_cache, and passenger counts are left to the schema, which already documents them 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?

States a specific resource and verb: cheapest Wizzair fare per day around a date, with an explicit ±day_interval window cap. It also names the sibling tools it is not (timetable, flight_dates), so an agent can discriminate it without opening any 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?

Explicitly routes the agent: use wizzair_search_timetable for departure times and wizzair_search_flight_dates for operating days, which covers the two most likely confusions. It does not address wizzair_search_flights (presumably the booking path), so the routing is strong but not exhaustive.

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?

With no annotations, the description carries the full burden and does well: it discloses that data comes live from Wizzair's private booking API and is unofficial, so it may briefly fail if Wizzair rotates or throttles it — a real reliability caveat an agent needs. It omits result-size/rate-limit behavior and does not restate the caching behavior (left to the schema's no_cache).

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 tight sentences with zero filler: the purpose and speed advantage come first, the data-source caveat second. Every clause earns its place.

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 five parameters, no annotations, and no output schema, the description covers purpose, intended workflow position, and reliability risk. It stops short of hinting at the response shape (a list of dates), which would have closed the remaining gap, but overall it is sufficient to invoke the tool correctly.

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 100%, so all five parameters (including no_cache and the date patterns) are already documented in the schema. The description reinforces the route + from/to window shape but adds no format or syntax detail beyond it — baseline 3 applies.

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 concrete resource — the dates on which a route has available Wizzair flights within a from/to window — with enough specificity to distinguish it from the fare-search sibling ('before asking for prices'). The verb is implicit (a list/discovery operation) rather than named, which keeps it just below a 5.

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 fastest way to see which days a route operates before asking for prices' gives clear sequencing: use this for date discovery, then move to pricing. It does not explicitly name wizzair_search_fares or wizzair_search_timetable as the alternatives, so the routing is inferred rather than stated.

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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses that the endpoint is experimental, sits behind Kasada bot protection, may return rate-limited errors, and depends on an unofficial private API that can briefly fail. It also names the recommended fallback. It lacks details on retry/backoff behavior or result-cache semantics, but the major reliability traits are 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 front-loaded with the EXPERIMENTAL warning and the core purpose, then follows with fallback guidance and data-source caveats. Every sentence adds useful information with no repetition or filler.

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 external-API search tool with no output schema, the description explains both the return content (fare bundles, prices, flight numbers, times) and the operational risks and fallbacks. Together with the fully documented schema, an agent has enough context to call it correctly and handle failure modes.

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 100%, so all nine parameters are fully documented in the schema itself, establishing a baseline of 3. The description reinforces the WDC pricing context but does not add syntax or meaning beyond the schema for individual parameters.

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 states a specific verb and resource: detailed Wizzair flights for exact dates with fare bundles. It enumerates what is included (Basic/WIZZ Go/WIZZ Plus pricing, flight numbers, exact times), which clearly distinguishes it from sibling tools that provide timetables or fare calendars. An agent can tell what this tool returns without opening the 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?

Usage is clearly implied for exact-date searches with detailed fare bundle pricing, and it explicitly names fallback alternatives (wizzair_search_timetable or wizzair_search_fares) when the endpoint is rate-limited. It does not explicitly say when to choose this over wizzair_search_flight_dates or wizzair_search_routes, but the exact-date focus provides sufficient context.

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?

With no annotations, the description carries the full burden and does so well: it discloses a 6-hour cache, that data comes from an unofficial private booking API, and that calls may briefly fail on rotation or throttling. Those are exactly the operational traits an agent needs before calling.

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 the core behavior and mode split, and the closing note about the `connections`/`cities` key being never `routes` is a genuinely useful gotcha. The enumerated result-shape sentence partly duplicates the output schema, costing some tightness.

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?

Covers both call modes, caching, upstream fragility, and the response key naming trap, which is everything an agent needs to invoke and parse correctly. The output schema exists, so the extra shape detail is surplus rather than a gap.

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 100%, so the baseline is 3, but the description adds real meaning by tying the presence/absence of `station` to the response `mode` and shape. It does not explicitly connect the 6-hour cache note to the `no_cache` bypass parameter, leaving that inference to the 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 ('list its direct connections' / 'list every Wizzair city with its destination count') and makes the route-network scope distinct from the fare/flight/timetable siblings. An agent can tell immediately this is the network-topology tool, not a schedule or pricing tool.

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 branches usage on the `station` parameter: supply it for one station's connections, omit it for the full city list. It does not name the sibling tools or say when to prefer wizzair_search_flights/timetable instead, so it stops short of full alternative routing.

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?

With no annotations, the description carries the full burden and rises to it partly: it discloses live data from Wizzair's private booking API, flags it as unofficial, and warns it may briefly fail on rotation or throttling. It also names the currency of returned prices. It omits cache behavior (only hinted at via the no_cache param) and whether results can be partial.

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 sentences, front-loaded with what you get per day, then the reliability caveat. Dense but nearly every clause adds information; the parenthetical 'unofficial — may briefly fail' is the only slightly compressed piece.

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 9-parameter search with no output schema, the description explains the per-day return shape (price plus departure datetimes) well enough to call correctly. The main missing piece is cache/refresh semantics, which is important here given the no_cache parameter and live-source fragility.

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 100%, so all nine parameters are already documented in the schema, including WDC, pax counts, and no_cache. The description adds only the notion that prices are in the route's local currency and that this is the outbound leg; baseline 3 applies.

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 ('Wizzair daily prices AND all departure times on a route in a from/to window'), with the outbound-leg scope called out explicitly. It is understandable without opening the schema, though it doesn't explicitly name which sibling (fares, flight_dates, flights) is the alternative.

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 'outbound leg' scope and the from/to window imply how it fits alongside wizzair_search_fares and wizzair_search_flight_dates, but the description never states when to prefer this tool or when to avoid it. Usage is inferable rather than directed.

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