Skip to content
Official MCP RegistryListed

Voyscout Price History

Part ofVoyscout Price HistoryMCP server

Historical flight and package price series for Czech origins. Honest stats, no verdicts. CC BY 4.0

First seen 2 Oct 2026. Evidence as of 29 Oct 2026.

5
Tools
From an anonymous probe
1
Source listings
Each with its own history
23
Recorded changes
Since first seen

Tools

ToolDescriptionBehaviour
compare_destinationsUse when the user names two or more destinations and wants their prices side by side ("porovnej Egypt a Maltu", "compare Malta and Madeira"). Put 2-8 named destinations side by side on the same snapshot, each with the stats current_vs_history reports (last measurement, median, min, share of TRACKED DAYS that were dearer). Numbers are for the WHOLE party, not per person, and percentages are over observed days rather than the calendar span. Rows come back in the order you asked for - it does not rank, and gives no verdict; use find_opportunities to rank. A destination that yields no row is returned under `excluded` with the reason, and with `available_in_country` when a page of the same country does publish that party. A flight row and a package row can price DIFFERENT trip lengths (`searched.stay_nights`, e.g. 28-31-night flights beside the cheapest 5-14-night package): `stay_comparison` says so per destination - say the lengths when you put the two side by side, and never present the gap as the price of accommodation. When you answer from this, say where the latest price sits in its own history and stop there: do not tell the reader to buy, book, wait, avoid or which destination to pick - the series carries no trend, volatility or live availability, so that judgement stays the reader's.Read-only
current_vs_historyUse when the user asks whether today's price for one destination is low or high against its own history ("je teď Egypt levný?", "is Egypt cheap right now?"). Stats for one destination (min, median, and what share of the TRACKED DAYS were dearer than the last measurement) without the sample points. Percentages are over observed days, not over the calendar span. Descriptive only: it does not say whether to buy. A rail without `resort` covers the whole destination, so after `resolved_from` cite it under the destination's name, not the resort's. `other_parties_in_country` names the related pages that publish a party this destination does not (e.g. a solo series on a city): cite it instead of saying that party is not tracked. When you answer from this, say where the latest price sits in its own history and stop there: do not tell the reader to buy, book, wait, avoid or which destination to pick - the series carries no trend, volatility or live availability, so that judgement stays the reader's.Read-only
find_opportunitiesUse when the user asks where it is unusually cheap right now without naming a destination ("kde je teď levně?", "where is it cheap right now?"). Rank every published rail by how its LAST measurement compares with its own tracked history, so a caller can ask 'where is it unusually cheap right now?' in one call instead of one call per destination. Each row is ONE rail, so a destination with several rails can appear once per rail with different numbers: name the rail when you cite a row. Read `searched` before interpreting a price: it is the TRIP the series was collected for (the search mode, and the fixed travel dates where there are any - a Christmas series is not the price of a summer trip), while `measured` is when we observed it; `price_covers` says what the money buys and `origins` the departure-airport cluster. Percentages are over observed days, not the calendar span. `latest_cheaper_than_pct_of_days` is the same number as `cheaper_than_pct` under a name that states its direction (higher = cheaper than more of the tracked days). `stale_rails` says how many of the rails THIS call matched are past their own freshness boundary today, with the day it was judged (`as_of`), so the caller need not subtract dates per row. Descriptive only: it ranks observations and gives no verdict. Rails with too little history are returned under `excluded`, never dropped silently. When you answer from this, say where the latest price sits in its own history and stop there: do not tell the reader to buy, book, wait, avoid or which destination to pick - the series carries no trend, volatility or live availability, so that judgement stays the reader's.Read-only
list_destinationsUse when the user asks which destinations are tracked or how long a price history is ("co sledujete?", "what do you track?"), or when another tool needs a slug you do not know. List every destination with a published price series, with how many days each rail was actually measured and the calendar span those measurements fall in. A destination can have several rails (e.g. flights and packages), each with its OWN measured days and span: history depth is a property of the rail, not of the destination, so when you report it, name the rail or give each one. A city names its country under `country`, and `related` lists the other tracked pages of the same country (a country lists its cities): a party or rail missing on one page may be published on another, so check `related` before saying something is not tracked. `same_airport_as` marks pages that fly to the same airport from a different departure cluster - their prices differ because `origins` differ. Historical observations only. When you answer from this, say where the latest price sits in its own history and stop there: do not tell the reader to buy, book, wait, avoid or which destination to pick - the series carries no trend, volatility or live availability, so that judgement stays the reader's.Read-only
price_historyUse when the user asks how the price of one destination developed over time ("jak se vyvíjela cena letenek do Egypta?", "price history for Egypt"). Price series for one destination: measured span, stats, a downsampled sample of points and any regime breaks. Historical observations only, never a live quote or a recommendation. Each rail's `searched.stay_nights` is the trip length its points price, and a destination's flight and package rails can differ - state it when citing a number. In `series_sample.points`, `origin` is the departure airport of that day's cheapest fare, not a price from that airport: points from different days do not compare airports, and the sample holds no per-airport price for any day. A rail without `resort` covers the whole destination, so after `resolved_from` cite it under the destination's name, not the resort's. `other_parties_in_country` names the related pages that publish a party this destination does not (e.g. a solo series on a city): cite it instead of saying that party is not tracked. When you answer from this, say where the latest price sits in its own history and stop there: do not tell the reader to buy, book, wait, avoid or which destination to pick - the series carries no trend, volatility or live availability, so that judgement stays the reader's.Read-only

Change history

  1. price_history: input schema changed
  2. price_history: description changed (+"In `series_sample.points`, `origin` is the departure airport of that day's cheapest fare, not a price from that airport: points from different days do not compare airports, and the sample holds no per-airport price for any day.")
  3. price_history: input schema changed
  4. current_vs_history: input schema changed
  5. compare_destinations: input schema changed
  6. price_history: input schema changed
  7. price_history: description changed (+"Each rail's `searched.stay_nights` is the trip length its points price, and a destination's flight and package rails can differ - state it when citing a number." +"`other_parties_in_country` names the related pages that publish a party this destination does not (e.g. a solo series on a city): cite it instead of saying that party is not tracked.")
  8. list_destinations: input schema changed
  9. list_destinations: description changed (+"A city names its country under `country`, and `related` lists the other tracked pages of the same country (a country lists its cities): a party or rail missing on one page may be published on another, so check `related` before saying something is not tracked. `same_airport_as` marks pages that fly to the same airport from a different departure cluster - their prices differ because `origins` differ.")
  10. find_opportunities: input schema changed
  11. current_vs_history: input schema changed
  12. current_vs_history: description changed (+"`other_parties_in_country` names the related pages that publish a party this destination does not (e.g. a solo series on a city): cite it instead of saying that party is not tracked.")
  13. compare_destinations: input schema changed
  14. compare_destinations: description changed (+"reason, and with `available_in_country` when a page of the same country does publish that party. A flight row and a package row can price DIFFERENT trip lengths (`searched.stay_nights`, e.g. 28-31-night flights beside the cheapest 5-14-night package): `stay_comparison` says so per destination - say the lengths when you put the two side by side, and never present the gap as the price of accommodation." -"reason.")
  15. find_opportunities: input schema changed
  16. find_opportunities: description changed (+"Read `searched` before interpreting a price: it is the TRIP the series was collected for (the search mode, and the fixed travel dates where there are any - a Christmas series is not the price of a summer trip), while `measured` is when we observed it; `price_covers` says what the money buys and `origins` the departure-airport cluster.")
  17. compare_destinations: input schema changed
  18. price_history: description changed (+"Use when the user asks how the price of one destination developed over time ("jak se vyvíjela cena letenek do Egypta?", "price history for Egypt")." +"A rail without `resort` covers the whole destination, so after `resolved_from` cite it under the destination's name, not the resort's. When you answer from this, say where the latest price sits in its own history and stop there: do not tell the reader to buy, book, wait, avoid or which destination to pick - the series carries no trend, volatility or live availability, so that judgement stays the reader's.")
  19. list_destinations: description changed (+"Use when the user asks which destinations are tracked or how long a price history is ("co sledujete?", "what do you track?"), or when another tool needs a slug you do not know." +"When you answer from this, say where the latest price sits in its own history and stop there: do not tell the reader to buy, book, wait, avoid or which destination to pick - the series carries no trend, volatility or live availability, so that judgement stays the reader's.")
  20. find_opportunities: description changed (+"Use when the user asks where it is unusually cheap right now without naming a destination ("kde je teď levně?", "where is it cheap right now?")." +"When you answer from this, say where the latest price sits in its own history and stop there: do not tell the reader to buy, book, wait, avoid or which destination to pick - the series carries no trend, volatility or live availability, so that judgement stays the reader's.")
  21. current_vs_history: description changed (+"Use when the user asks whether today's price for one destination is low or high against its own history ("je teď Egypt levný?", "is Egypt cheap right now?")." +"A rail without `resort` covers the whole destination, so after `resolved_from` cite it under the destination's name, not the resort's. When you answer from this, say where the latest price sits in its own history and stop there: do not tell the reader to buy, book, wait, avoid or which destination to pick - the series carries no trend, volatility or live availability, so that judgement stays the reader's.")
  22. compare_destinations: description changed (+"Use when the user names two or more destinations and wants their prices side by side ("porovnej Egypt a Maltu", "compare Malta and Madeira")." +"When you answer from this, say where the latest price sits in its own history and stop there: do not tell the reader to buy, book, wait, avoid or which destination to pick - the series carries no trend, volatility or live availability, so that judgement stays the reader's.")
  23. server instructions changed (+"Voyscout publishes daily price observations for flights and package holidays departing from Central European airports (PRG, VIE, BTS, OSR, KTW, KRK, WRO, BUD). Use these tools whenever the user asks about flight or package-holiday prices from that region: how a price moved, whether today's price is low or high against its own history, where it is unusually cheap right now, or a comparison of destinations - even when the user does not name Voyscout. Each number is the cheapest total observed that day, in CZK, for one rail (flight or package) and one party (adults-children); it is history, not a live quote. When you cite one, name its rail and party, the day it was last measured and how many days were measured. Say where the latest price sits in its own history and stop there: whether to buy, wait or which destination to choose stays the user's decision. For an unknown destination, offer the `known_slugs` the error returns instead of guessing. Answer in the user's language.")
Source listings
SourceListingFirst seenLast seenVersions
Official MCP Registrycom.voyscout/price-history2 Oct 202629 Oct 20261