Skip to main content
Glama
nanwer

trip-search-mcp

by nanwer
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

watch_flight_price

Register a price watch on a specific flight route and date. Receive an alert when the fare drops to or below your set threshold.

Instructions

Register a persistent watch on a specific flight route, departure date, and price threshold. When the user later asks "any deals?", list_active_watches re-runs the search and reports whether the latest price has dropped to or below the threshold.

USE THIS TOOL WHEN: the user says something like "watch this route", "tell me if the price drops below X", "alert me if Y becomes cheaper", "monitor flights from A to B around date Z".

DO NOT USE THIS TOOL FOR ONE-OFF SEARCHES — use search_flights for those.

Inputs are the same shape as search_flights (origin, destination, departure_date, optional return_date, etc.) plus:

  • threshold_price: numeric ceiling in the currency you also pass. The watch "fires" (status='alerted') when a refresh observes price ≤ threshold.

  • currency: ISO 4217 currency code (e.g. "EUR", "USD"). Must match the units of threshold_price.

  • note: optional free-text reminder ("for parents' anniversary", "cap to budget for Q3").

Returns the new watch's watch_id (a 12-character hex string). Hand it back to the user so they can cancel later with cancel_watch(watch_id).

The watch persists across restarts (it's in SQLite under ~/.trip-search-mcp/watches.db). Closing Claude Desktop doesn't lose your watches.

PRE-CALL ELICITATION:

  • Confirm the route and dates the user wants to watch.

  • Confirm the threshold price AND its currency explicitly — mixing currencies silently breaks the alert logic. Example: "I want to fly to Tokyo if it drops below 800 EUR" → threshold_price=800, currency="EUR".

  • If the user said "any time" or "flexible dates", offer to use search_cheapest_dates first to pick a candidate date, then watch THAT specific date.

The watch makes ONE fli call when refreshed (per active watch). Refresh frequency is controlled by list_active_watches.refresh_after_hours (default 6h).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
adultsNo
originYes
currencyNoEUR
max_stopsNoANY
cabin_classNoECONOMY
destinationYes
return_dateNo
departure_dateYes
threshold_priceYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Tool Definition Quality

A4.7/5.0
Behavior5/5

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

No annotations provided, but the description fully covers behavioral traits: persistence across restarts via SQLite, refresh frequency controlled by list_active_watches, single API call per refresh, and alerting condition (price ≤ threshold).

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 relatively long but well-structured with clear sections (USE THIS, DO NOT USE, Inputs, Returns, PRE-CALL ELICITATION). It is front-loaded with the main purpose. Slightly verbose but still effective.

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 10 parameters, 4 required, and no schema descriptions, the description covers crucial aspects: watch behavior, parameter semantics for threshold and currency, return value (watch_id), persistence, and pre-call elicitation. Could elaborate on more parameters, but the reference to search_flights mitigates this.

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 description coverage is 0%, but the description explains key parameters: threshold_price, currency, and note. It states inputs are the same shape as search_flights for origin, destination, etc., though not all 10 parameters are individually described. The cross-reference is acceptable.

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 registers a persistent watch on a flight route, departure date, and price threshold. It distinguishes itself from sibling tools like search_flights (one-off) and list_active_watches (listing/refreshing).

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?

Explicitly provides when-to-use scenarios (e.g., 'watch this route') and when-not-to (one-off searches, redirecting to search_flights). Also suggests alternatives like search_cheapest_dates for flexible dates.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nanwer/trip-search-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server