Loading ToolBench
This MCP allows you to search for flights using the Aviasales Flight Search API. You can specify flight segments, number of passengers, trip class, currency, and locale, apply various filters, and retrieve detailed flight options.
The server defines 2 tools with detailed input schemas and reasonable descriptions. Both tools have comprehensive parameter documentation with constraints and format specifications. However, there are moderate gaps in output schema documentation, error handling guidance, and some parameter design issues that prevent a higher score. The tools follow the pattern:tool naming convention well ('search_flights', 'get_flight_options'), but lack output schema documentation and have incomplete error recovery guidance.
Get flight options from the previously performed search. This tool allows you to filter the found flight options by price, departure and arrival times, and airlines. It returns a paginated list of flight options that match the specified filters and sorting option. IMPORTANT: This is very cheap operation, so you can call it as many times as needed to find the best flight options.
Search for flights using the Aviasales Flight Search API. This tool performs search based on the provided flight segments, number of passengers, trip class, currency, and locale. It provides search_id and description of search results and saves found options internally. After receiving the result client can use `get_flight_options` tool to retrieve the found options with more granular filters. IMPORTANT: All times are local to departure/arrival locations and use HH:MM 24-hour format. IMPORTANT: Call this tool as many times as needed to find the best flight options.
Output schemas not documented. Tool descriptions and code do not specify what fields are returned, making it difficult for LLMs to plan downstream operations and extract specific data for follow-up calls.
Error handling lacks recovery guidance. The code raises ToolError with basic messages ('Aviasales API returned non-200 status code...', 'Unexpected response format...') without actionable next steps or classification (retryable vs user-fixable vs fatal).
Required environment variables (FLIGHTS_AVIASALES_API_TOKEN, FLIGHTS_AVIASALES_MARKER) are checked at module import time and will crash the server if missing. This creates a hard dependency that should be handled more gracefully or documented clearly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Parameter 'locale' accepts free-form strings in description but should be constrained to enum: en-us, en-gb, ru, de, es, fr, pl. Current implementation allows LLMs to pass invalid values.
Parameter 'trip_class' is defined as free-form string with default 'Y', but description says 'single letter: Y for economy, C for business' without enforcing via enum or pattern.
search_flights description mentions 'get_flight_options' tool but does not explain what fields are in the returned search_id or how to use it, missing context for composition.
get_flight_options filters parameter 'allowed_airlines' accepts array of airline IATA codes but lacks description of valid format (e.g. 'Two-letter IATA airline codes, e.g. UA, AA, BA').