What can you do with this server?

Air Choose is a read-only MCP server for monitoring flight prices across multiple airline providers, detecting price drops, and retrieving offers — no booking or ticket ordering capabilities included. * List providers (list_providers): See available airlines (Kupibilet, Ryanair, SpiceJet, Jetstar Asia), their coverage regions, and requirements. * Resolve location codes (resolve_location): Convert human-readable place names (e.g. "Moscow", "Thailand", "BKK") into each provider's internal airport/city/country codes. * Add a watched route (add_watch): Start monitoring a specific origin–destination–date range, with optional max price and currency filters. An immediate first check runs automatically. * Remove a watch (remove_watch): Stop monitoring a route and clear its price history. * List current watches (list_watches): View all monitored routes, including last check time and offer count. * Get offers for a watch (get_watch_offers): Retrieve the latest known flight offers for a specific watch, sortable by price or date. * Poll for new/cheaper offers (poll_new_offers): Fetch and clear all newly discovered offers (new routes or price drops below the previous best) across all watches since the last poll — the primary way to detect changes. * Force an immediate check (force_check): Trigger an on-demand fare check for a specific watch without waiting for the hourly scheduled cycle.

Which integrations are available for this server?

Allows monitoring of flight fares from Ryanair's API for European routes, including tools for location resolution, route watching, and polling for new offers.

How do I use air_choose?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@air_choose start watching flights from Moscow to Thailand in November" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

air_choose

by bitwiresys

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Read-only MCP server that monitors flight prices across multiple airline providers. An AI agent (Hermes, OpenClaw, Claude, etc.) adds, removes, and inspects watched routes through MCP tools; a background scheduler re-checks every watch hourly and queues new/cheaper offers for the agent to pick up. No ticket ordering — only available flight data.

Features

Multi-provider — Kupibilet (worldwide), Ryanair (Europe), SpiceJet (India), Jetstar Asia (Asia-Pacific)
Flights only — trains and other transport types are filtered out automatically
Smart resolution — turn "Moscow → Thailand" into provider-specific airport/country codes
Price drop detection — tracks best-ever prices per route, queues notifications when fares drop
MCP-native — works with any MCP-compatible agent host

Related MCP server: bhinneka

Quick Start

Local

git clone https://github.com/yourusername/air-choose.git
cd air-choose
npm install
node src/server.js

Docker

docker compose up -d

Wire into your agent

{
  "mcpServers": {
    "air-choose": {
      "command": "node",
      "args": ["/absolute/path/to/air-choose/src/server.js"]
    }
  }
}

Configuration

Env Variable	Default	Description
`AIR_CHOOSE_INTERVAL_MS`	`3600000` (1 hour)	Scheduler re-check interval

Tools

Tool	Purpose
`list_providers`	See airline providers, coverage, browser requirements
`resolve_location`	Turn a place name into each provider's own codes
`add_watch`	Add a route to monitor (resolves + runs first check immediately)
`remove_watch`	Stop watching a route
`list_watches`	See everything currently watched
`get_watch_offers`	Current offers for one watch, sorted by price or date
`poll_new_offers`	Return + clear everything new since last call
`force_check`	Re-run a watch's check right now

Providers

Provider	Coverage	Auth	Notes
Kupibilet	Worldwide	No	Accepts ISO2 country codes directly
Ryanair	Europe	No	Can rate-limit (409) under heavy use
SpiceJet	India	Auto token	Calendar view, no exact departure times
Jetstar Asia	Asia-Pacific	Browser session	Excluded by default (Akamai)

Architecture

MCP Client (Hermes / Claude / ...)
        | JSON-RPC (stdio)
air-choose server
  |-- Tools (8)
  |-- Scheduler (hourly)
  |-- Provider Adapters (Kupibilet | Ryanair | SpiceJet | Jetstar)
  |-- JSON Store (watches | offers | pending)

Example Flow

Agent -> resolve_location({ query: "Moscow" })
Agent -> resolve_location({ query: "Thailand" })
Agent -> add_watch({
           originQuery: "Moscow",
           destinationQuery: "Thailand",
           dateFrom: "2026-07-21",
           dateTo: "2026-08-20"
         })
        -> Server resolves, runs check, returns offers sorted by price

... one hour later, scheduler re-checks ...

Agent -> poll_new_offers()
        -> Returns new or cheaper offers found since last poll

Testing

npm test           # unit tests
npm run test:e2e   # end-to-end (hits live APIs)
npm run test:all   # all tests

Legal

Reverse-engineered consumer-facing endpoints, not published partner APIs. Keep the hourly interval reasonable.

License

MIT

Available Tools

8 tools

add_watchAdd a watched routeA

Add a route to monitor. originQuery/destinationQuery go through the same resolution as resolve_location for every requested provider, immediately, and the watch stores each provider’s resolved codes — you get that resolution back in the response so you can sanity-check it before relying on the watch. An immediate first check runs right away (you do not have to wait for the hourly cycle to get initial results) and its offers are returned too.

ParametersJSON Schema

Name	Required	Description
`label`	No	Free-text label to help you recognize this watch later
`dateTo`	Yes	YYYY-MM-DD
`currency`	No	Preferred currency code for providers that support choosing one (Kupibilet, SpiceJet). Providers ignore this if they don’t support it and return their own default currency instead — always read the currency field on each offer.
`dateFrom`	Yes	YYYY-MM-DD
`maxPrice`	No	Ignore offers above this price (in each provider’s own currency)
`providers`	No	Provider ids to search; defaults to providers that work without a browser session (currently ryanair, kupibilet, spicejet). Pass ["jetstar"] explicitly to try it anyway.
`originQuery`	Yes	e.g. "Москва" / "Moscow" / "MOW"
`destinationQuery`	Yes	e.g. "Таиланд" / "Thailand" / "BKK"

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description fully explains behavioral traits: immediate resolution of locations, storage of codes, and an immediate first check returning offers. It lacks details on idempotency or duplicates but is otherwise transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core purpose, and efficiently explains complex behavior without redundancy. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters and no output schema, the description covers resolution, immediate check, and response contents. It could mention duplicate handling or resource limits but is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage with detailed descriptions. The tool description adds context about resolution and immediate check but does not significantly enhance per-parameter semantics. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Add a route to monitor' and explains the watch's purpose, distinguishing it from sibling tools like list_watches or remove_watch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but does not explicitly state when to use it versus alternatives like force_check or poll_new_offers. The context is implied but not clearly demarcated.

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

force_checkForce an immediate checkB

Re-run the fare check for one watch right now, instead of waiting for the hourly cycle.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states 're-run', but does not disclose potential side effects, authentication needs, or rate limits. Transparency is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with key action and benefit, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter, no output schema, and no annotations, the description is insufficient. It does not cover parameter provenance or usage context, leaving the agent underinformed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the single parameter 'id'. The agent has no way to know what value to provide. Requires compensation from description, which is absent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 're-run' and the resource 'fare check for one watch', and distinguishes from waiting for the hourly cycle. It is specific and precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (immediate check instead of waiting), but does not provide exclusions or mention alternative tools like poll_new_offers. Clear context but lacks explicit guidance.

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

get_watch_offersGet current offers for a watchB

Return the latest known offers for a watch, from the most recent check (hourly, or forced).

ParametersJSON Schema

Name	Required	Default
`id`	Yes
`limit`	No
`sortBy`	No	price

TDQS

B3.3/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. States it returns 'latest known offers' from 'most recent check', implying potential staleness. Lacks details on error handling, auth needs, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, efficient, front-loaded with purpose. No extra words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 parameters and no output schema/annotations, the description is minimal. Lacks info on output format, pagination, sorting behavior, or handling missing watch.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must compensate. Only mentions 'from most recent check' without explaining 'limit' or 'sortBy'. No additional meaning beyond param names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb (return), resource (offers for a watch), and context (latest known, from most recent check). Distinguishes from siblings like 'force_check' and 'poll_new_offers'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives like 'poll_new_offers' or 'force_check'. The description implies it's for current offers but doesn't clarify conditions.

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

list_providersList flight/ticket providersA

List every provider air_choose can query, with its coverage region and whether it needs a live browser session (those are NOT included here — only providers that work with plain HTTP calls are).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description fully discloses the scope: it only lists providers that work with plain HTTP calls, and mentions that providers needing a live browser session are not included. This is transparent about what is returned and what is filtered out, though no additional behavioral details (e.g., rate limits) are provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys purpose, included fields, and an important exclusion. No wasted words, and the key action is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains the return value (list of providers with coverage region and browser requirement flag) and the exclusion of browser-dependent ones. For a simple parameterless tool, this is complete enough for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the schema coverage is 100% (trivially). The description does not need to add parameter information, so the baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists providers that air_choose can query, specifying the information included (coverage region and whether it needs a live browser session) and explicitly excluding providers that require live sessions, making the purpose highly specific and distinct from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description sets clear expectations on when to use this tool (to list HTTP-only providers) and implies that providers needing a live session are not covered, but does not explicitly name alternative tools for those providers. Sibling tools have different functions, so the usage context is clear.

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

list_watchesList watched routesA

List every currently watched route, with when it was last checked and how many offers it has.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It describes the operation as 'list', implying a read-only behavior, but does not explicitly state there are no side effects or rate limits. Adequate but could be more transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 15 words, non-redundant, and front-loaded with the action. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no output schema, and low complexity, the description is sufficient. It specifies what is returned (last checked, offer count). Could mention if results are paginated, but not necessary for such a simple list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters and 100% coverage, so the baseline is 4. The description adds no parameter info, but none is needed since there are no parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list', the resource 'watched routes', and the specific data returned (last check time, offer count). This distinguishes it from siblings like 'list_providers' which lists providers, not routes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (to see watched routes), but does not explicitly mention when not to use it or provide alternatives like 'force_check' or 'get_watch_offers' for more details. No guidance beyond the basic purpose.

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

poll_new_offersPoll for newly found offers (main wake-up tool)A

Return every offer discovered since the last time this was called — new routes/dates appearing, or a price drop below the previously-seen best price — across ALL watches, and clears the queue. This is the reliable way to find out "what changed": call it on your own schedule (e.g. once an hour) rather than relying on push notifications, since not every MCP host wakes an idle agent on server notifications.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

Discloses that it 'clears the queue' (destructive behavior) and that it returns a cumulative set since last call. No annotations are provided, so this description carries the full burden. Could mention rate limits or auth but adequate for a 0-param polling tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Highly concise: two sentences that front-load the key behavior and follow with usage guidance. No redundancy or extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description explains return type, behavior (clearing queue), and scheduling advice. Could mention what happens when no new offers, but overall complete for a simple polling tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%. Baseline of 4 applies as the description adds no parameter information, which is acceptable for zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns new offers (routes/dates or price drops) since last call across all watches. It distinguishes itself as the 'main wake-up tool' and the reliable way to find changes, thus differentiating from siblings like get_watch_offers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to call on own schedule (e.g., hourly) rather than relying on push notifications. Implicitly contrasts with notification-based tools. Lacks explicit when-not-to-use but provides clear context for appropriate use.

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

remove_watchRemove a watched routeA

Stop monitoring a route and forget its price history.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It transparently states the destructive action (stop monitoring) and that price history is forgotten, which implies irreversibility. This is sufficient for a simple delete operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence conveying the entire purpose without any fluff. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one required parameter, no output schema), the description is largely complete. However, it could mention error handling (e.g., behavior if ID doesn't exist) or return value.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description adds no meaning to the 'id' parameter—it does not specify what the ID represents (e.g., a watch identifier). The parameter remains under-documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Stop monitoring a route and forget its price history,' clearly indicating the tool's action and distinguishing it from siblings like add_watch (adds a watch) and list_watches (lists watches).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives (e.g., when you want to stop tracking vs. pause tracking). The description is purely functional without contextual usage advice.

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

resolve_locationResolve a place name to each provider’s own codesA

Every provider uses its own internal airport/city/country codes — you cannot just pass a Russian or English place name straight into a search. Call this FIRST for both the origin and the destination before add_watch, so you can see what each provider actually understood the place as. Accepts a country name (RU or EN, e.g. "Таиланд" / "Thailand"), a 3-letter IATA code (e.g. "BKK"), or a handful of built-in city aliases (Moscow, London, Singapore, Delhi, ...). Returns, per provider, the list of matched airports/cities/country codes — an empty list for a provider means that provider does not serve that place at all (e.g. Ryanair has no Moscow routes), which is normal, not an error.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Place name or code to resolve, e.g. "Москва", "Thailand", "BKK"
`providers`	No	Provider ids to resolve against; defaults to providers that work without a browser session (currently ryanair, kupibilet, spicejet). Pass ["jetstar"] explicitly to try it anyway — it usually 409s without a browser-derived cookie, see list_providers.requiresBrowserSession.

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: acceptable input types (country names in RU/EN, IATA codes, built-in aliases), per-provider return, empty list meaning no service (not an error), and provider parameter defaults with a note about jetstar requiring browser cookie. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph of moderate length. It is front-loaded with the key instruction and then provides details on inputs and outputs. Every sentence adds value, though it could be slightly restructured for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 2 parameters, no output schema, but moderate complexity, the description thoroughly covers input semantics, return format, edge cases (empty list, jetstar), and ties to sibling tool add_watch. It leaves no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds significant meaning by explaining the types of valid inputs for 'query' (country names, IATA codes, aliases) and for 'providers' (defaults, jetstar special case). This goes beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to resolve place names to provider-specific internal codes. It distinguishes from siblings by explicitly instructing to call this before add_watch, making the resource and action clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'Call this FIRST for both the origin and the destination before add_watch.' It also explains what empty results mean and notes the default providers and special case for jetstar, giving when-to-use and when-not-to-use context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.0Jul 10, 2026
- First observedadd_watch
- First observedforce_check
- First observedget_watch_offers
- First observedlist_providers
- First observedlist_watches
- First observedpoll_new_offers
- First observedremove_watch
- First observedresolve_location

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Scored 2026-07-10 21:50 across 8 tools

Disambiguation5/5

Each tool targets a distinct action: add_watch, force_check, get_watch_offers, list_watches, remove_watch all operate on watches but with different operations; list_providers, poll_new_offers, and resolve_location are entirely separate concerns. No overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_watch, list_providers, resolve_location). The naming is predictable and clear throughout.

Tool Count5/5

8 tools is appropriate for an airfare monitoring server. It covers all necessary operations without being bloated or too sparse.

Completeness4/5

The toolset covers the full lifecycle of watch management (create, read, delete, force check) plus location resolution and provider listing. A minor gap is the lack of an update watch functionality, but this is not critical for the core use case.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Flight MCP
com.flight-mcp
Search and compare flight offers through a cache-aware Streamable HTTP MCP server for AI agents.
Travel & Transportation Search
1
ALLFLYGHTS
io.github.dev-allflyghts
Geo-based flight search MCP server. Find more flights between any two places on earth
Travel & Transportation Location Services
2
Skiplagged MCP A
com.skiplagged
Skiplagged MCP Server for flight search, hotel booking, and travel planning
Travel & Transportation Search E-commerce & Retail
105
World Airfares Flight Search A
com.worldairfares
Flight search MCP server providing search, pagination, and itinerary details for AI assistants.
Travel & Transportation Search
32

Related MCP Servers

flights-mcp
Travel & Transportation Search
fastmcp-me
A
license
A
quality
D
maintenance
An MCP server that provides flight search capabilities using the Aviasales API, allowing users to search, filter, and get details on flights and generate booking links.
Updated 8 months ago (2026-01-19 06:48 UTC)
4
GPL 3.0
bhinneka
Travel & Transportation Browser Automation Search
tistaharahap
F
license
Not graded
quality
D
maintenance
MCP server providing flight search, web search, URL fetching with JS rendering, and documentation search tools.
Updated a year ago (2025-09-17 05:24 UTC)
-
Travel MCP Cloudflare Worker
Travel & Transportation Web Scraping
jongan69
A
license
Not graded
quality
C
maintenance
A free, Cloudflare-hosted travel MCP server for flights, hotels, and Airbnb-style stays.
Updated a month ago (2026-08-14 18:28 UTC)
MIT
@theyahia/travelpayouts-mcp
Travel & Transportation Search
theYahia
A
license
Not graded
quality
B
maintenance
MCP server for the Travelpayouts (Aviasales) API. It provides 13 tools for flight search, price calendars, hotel search, and airport/airline/city lookup.
Updated 7 days ago (2026-09-06 08:41 UTC)
48
MIT