Historical flight and package price series for Czech origins. Honest stats, no verdicts. CC BY 4.0
Scored across 5 tools
Each tool has a clearly distinct purpose: list_destinations enumerates, price_history gives a full series, current_vs_history gives single-destination stats, compare_destinations does multi-destination comparisons, and find_opportunities ranks across all destinations. Descriptions explicitly disambiguate overlapping stats and ranking behavior.
Most names follow a verb_noun pattern (list_destinations, find_opportunities, compare_destinations), but price_history and current_vs_history are noun-like phrases rather than actions. The convention is not fully uniform, but it remains readable and predictable.
Five tools is well-scoped for a price history domain: one to list, one for series, one for single-destination stats, one for comparison, and one for ranking. Each tool earns its place without redundancy.
The surface covers the full read/analytics workflow: discovering available destinations, retrieving historical series, summarizing stats, comparing multiple destinations, and finding opportunities across all rails. No obvious dead ends or missing core operations for the stated historical purpose.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| rail | No | optional (default both): restrict to one rail | |
| party | No | optional (default '2-2'): '<adults>-<children>', the same A-C shape the price streams are keyed on | |
| destinations | Yes | 2-8 destination slugs; the answer keeps this order | |
| min_history_days | No | optional (default 30): rails measured for fewer days are listed under 'excluded' |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and destructiveHint=false, so safety is covered. Beyond that, the description discloses substantial behavioral traits: results are for the WHOLE party not per person, percentages are over observed days rather than calendar span, rows preserve request order, no ranking or verdict is given, and missing destinations appear under 'excluded' with a reason. No contradiction with annotations.
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?
Four sentences, each carrying unique operational meaning: scope, interpretation caveats, ordering/ranking behavior, and failure handling. The core purpose is front-loaded and no sentence is redundant filler, though 'does not rank' and 'gives no verdict' are slightly overlapping.
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 comparison tool with an output schema, the description is complete: it covers input constraints (2-8 destinations), output shape (requested order plus excluded with reasons), aggregation semantics (whole party, observed days), and routing to alternatives. Nothing an agent needs to call it correctly or interpret its results 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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying the party parameter's interpretation ('Numbers are for the WHOLE party, not per person') and reinforcing the destinations order guarantee. The min_history_days exclusion behavior is already in the schema, so the marginal addition is moderate rather than large.
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+resource: 'Put 2-8 named destinations side by side on the same snapshot' with a precise stat list. It also distinguishes itself from siblings by naming what it is not ('does not rank') and referencing current_vs_history as the source of its stats, so an agent can separate it from find_opportunities and list_destinations without opening schemas.
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 description gives clear context on when this tool fits: multi-destination side-by-side comparison with specific stats, and explicitly routes ranking tasks elsewhere ('use find_opportunities to rank'). It does not explicitly say 'use current_vs_history for a single destination,' but the framing of 'the stats current_vs_history reports' implies it is the multi-destination aggregation of that tool. One explicit exclusion and one implied alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| destination | Yes | destination slug, as returned by list_destinations. A RESORT key read off a rail (e.g. 'hurghada') also resolves, to its parent destination, and the answer then carries `resolved_from`; underscores and hyphens are interchangeable. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly/openWorld/destructive, and the description adds meaningful behavioral context: percentages are over observed days rather than the calendar span, and the result is descriptive only with no buy guidance. It also clarifies the response excludes sample points, which helps set expectations beyond what annotations convey.
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 brief sentences, front-loaded with the operation ('Stats for one destination'), followed by the key denominator caveat and then a boundary note. Every sentence earns its place, with no redundancy against the schema or annotations.
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 one-parameter, read-only tool with an output schema and fully documented parameters, the description covers the important semantic caveats that would otherwise be invisible: observed days vs calendar span, no sample points, and no buy advice. Nothing needed for correct invocation 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% and the destination parameter is fully documented in the schema itself (slug from list_destinations, RESORT resolution, resolved_from behavior, delimiter interchangeability). The description adds no parameter-specific details, which is acceptable because the schema carries that burden; 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 purpose: it returns summary stats (min, median, and share of tracked days dearer than the last measurement) for one destination while explicitly excluding sample points. The 'for one destination' and 'without the sample points' clauses differentiate it from siblings like compare_destinations and price_history, and 'does not say whether to buy' separates it from find_opportunities.
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?
Describes clear use context: one destination, summary stats, no sample points, no buy recommendation. It tells the agent what the tool will not do, but stops short of explicitly naming the alternative tool to use when those behaviors are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| rail | No | optional: restrict to one rail | |
| sort | No | optional (default cheapest_vs_history): 'cheapest_vs_history' ranks by the share of tracked days that were dearer; 'most_below_median' ranks by how far the last measurement sits below the median, relatively | |
| limit | No | optional (default 10): how many rows to return; 'matched' reports the count before the cap | |
| party | No | optional: '<adults>-<children>', e.g. '2-2' - the same A-C shape the price streams are keyed on | |
| min_history_days | No | optional (default 30): rails measured for fewer days are listed under 'excluded' |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only and non-destructive behavior, and the description adds substantial context beyond them: percentages are over observed days rather than calendar span, low-history rails are returned under excluded rather than silently dropped, stale_rails includes the as_of judgement day, and the tool is explicitly described as giving no verdict.
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 longer than minimal but every sentence earns its place: it front-loads the ranking purpose, then adds caveats and field clarifications that would otherwise cause misinterpretation. Backticked field names and a clear logical order keep it navigable despite its length.
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 tool with five optional parameters, read-only annotations, and an output schema, the description covers everything needed to call it correctly: cross-rail scope, history-threshold behavior, stale-rail handling, and the descriptive-only nature. Nothing critical is left ambiguous.
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 the baseline is 3. The description does not add material input-parameter meaning beyond the schema; it clarifies output-field semantics such as latest_cheaper_than_pct_of_days and stale_rails, which is useful but not parameter-level enrichment.
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 opens with a specific verb and resource: 'Rank every published rail by how its LAST measurement compares with its own tracked history.' It states the exact caller question ('where is it unusually cheap right now?') and contrasts it with one call per destination, making the tool's scope and its distinction from per-rail history lookups clear.
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?
It provides a clear context for use: a single cross-rail call to surface unusually cheap-vs-history opportunities. However, it does not explicitly name sibling alternatives such as current_vs_history or describe when not to use this tool, so it stops short of a full when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Historical observations only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about what data is included (published price series, days measured, calendar span) and the historical-only constraint. It doesn't describe pagination or result limits, but with zero parameters and an output schema present, this is acceptable.
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 with no wasted words. The core purpose is front-loaded, and the historical-only constraint is stated clearly at the end. Every word 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?
For a zero-parameter list tool with an output schema and read-only annotations, the description is nearly complete. It could explicitly mention that no filters or arguments are accepted, but the empty schema already conveys that. The historical-only scope is clearly stated.
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?
The tool has zero parameters, so the schema is trivially complete. The description adds meaning by explaining what the returned list contains, which is the only relevant semantic information. Baseline 4 for zero params is appropriate.
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 clearly states the tool lists every destination with a published price series, and specifies the exact information returned (days measured and calendar span). It distinguishes itself from siblings by focusing on historical observations only.
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 description implies this is for getting an overview of all destinations with historical data, and the 'Historical observations only' phrase clarifies scope. It doesn't explicitly name alternatives or when to use them, but the sibling context and clear scope provide adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| rail | No | optional: restrict to one rail | |
| destination | Yes | destination slug, as returned by list_destinations. A RESORT key read off a rail (e.g. 'hurghada') also resolves, to its parent destination, and the answer then carries `resolved_from`; underscores and hyphens are interchangeable. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond those flags: it is historical-only, never a live quote or recommendation, and returns a downsampled sample of points plus regime breaks. This clarifies the nature of the data and its limitations, complementing the annotations without contradicting them.
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 a single, well-structured sentence that front-loads the core purpose, then lists the key data components, and ends with exclusions. Every phrase adds information; there is no filler or redundancy.
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 the tool has only two parameters, an output schema, and safety annotations, the description covers the essential aspects: what data is returned, the historical-only nature, and the single-destination scope. The output schema handles return formatting, and the parameter schema covers the destination resolution nuance. No critical information for correct invocation 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 description coverage is 100%, so the baseline is 3. The tool description itself does not add parameter-level detail, but the schema descriptions for destination and rail are complete, including the resolved_from behavior and slug format. The description's high-level focus on the returned series is reasonable given the schema already handles parameter meaning.
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 opens with 'Price series for one destination,' a specific resource and scope, and enumerates the content: measured span, stats, downsampled sample, and regime breaks. The final sentence 'Historical observations only, never a live quote or a recommendation' differentiates it from siblings like current_vs_history and find_opportunities, so an agent can clearly distinguish it.
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 description clearly states the tool's scope ('for one destination') and explicitly excludes live quotes and recommendations, which implies when not to use it. However, it does not name sibling tools or give explicit 'use X instead' guidance, so it stops short of a fully explicit when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_destinations1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "comparison": {
+ "items": {
+ "properties": {
+ "arrivals": {
+ "description": "arrival airports RECORDED; covers_all_published_prices is false",
+ "type": "object"
+ },
+ "destination": {
+ "type": "string"
+ },
+ "generated": {
+ "type": "string"
+ },
+ "latest_stale_after_days": {
+ "description": "this rail's own freshness boundary, in days after measured.to",
+ "type": "number"
+ },
+ "measured": {
+ "properties": {
+ "days": {
+ "type": "integer"
+ },
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "days",
+ "from",
+ "to"
+ ],
+ "type": "object"
+ },
+ "origins": {
+ "description": "departure-airport CLUSTER; covers_all_published_prices is false",
+ "type": "object"
+ },
+ "party": {
+ "properties": {
+ "adults": {
+ "type": "integer"
+ },
+ "children": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "adults",
+ "children"
+ ],
+ "type": "object"
+ },
+ "price_covers": {
+ "description": "what the money buys - airfare only, or a package as offered",
+ "type": "object"
+ },
+ "rail": {
+ "enum": [
+ "flight",
+ "package"
+ ],
+ "type": "string"
+ },
+ "regime_breaks": {
+ "description": "[from, to] date spans where the series was not comparable",
+ "type": "array"
+ },
+ "resort": {
+ "type": "string"
+ },
+ "resort_key": {
+ "type": "string"
+ },
+ "searched": {
+ "description": "the search mode (and fixed dates, where there are any) the series was collected under",
+ "type": "object"
+ },
+ "stats": {
+ "properties": {
+ "basis": {
+ "type": "string"
+ },
+ "cheaper_than_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "is_series_max": {
+ "type": "boolean"
+ },
+ "is_series_min": {
+ "type": "boolean"
+ },
+ "latest": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "median": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "min": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "basis"
+ ],
+ "type": "object"
+ },
+ "title": {
+ "properties": {
+ "cs": {
+ "type": "string"
+ },
+ "en": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "cs",
+ "en"
+ ],
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "destination",
+ "title",
+ "url",
+ "generated",
+ "rail",
+ "party",
+ "price_covers",
+ "measured",
+ "stats"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "comparison_rows": {
+ "description": "rows, not destinations - a dual-rail destination contributes two",
+ "type": "integer"
+ },
+ "currency": {
+ "type": "string"
+ },
+ "disclaimer": {
+ "type": "string"
+ },
+ "excluded": {
+ "items": {
+ "properties": {
+ "destination": {
+ "type": "string"
+ },
+ "generated": {
+ "type": "string"
+ },
+ "measured": {
+ "properties": {
+ "days": {
+ "type": "integer"
+ },
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "days",
+ "from",
+ "to"
+ ],
+ "type": "object"
+ },
+ "party": {
+ "type": "string"
+ },
+ "rail": {
+ "enum": [
+ "flight",
+ "package",
+ "both"
+ ],
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "resort_key": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "destination",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "generated": {
+ "description": "the OLDEST `generated` among the rows and dated exclusions",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "license": {
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "attribution"
+ ],
+ "type": "object"
+ },
+ "min_history_days": {
+ "type": "integer"
+ },
+ "party": {
+ "type": "string"
+ },
+ "rail": {
+ "enum": [
+ "flight",
+ "package",
+ "both"
+ ],
+ "type": "string"
+ },
+ "schema": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "schema",
+ "generated",
+ "party",
+ "rail",
+ "min_history_days",
+ "comparison_rows",
+ "comparison",
+ "excluded",
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "tool-level failure, returned with isError: true",
+ "properties": {
+ "error": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}current_vs_history1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "currency": {
+ "type": "string"
+ },
+ "destination": {
+ "properties": {
+ "key": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "properties": {
+ "cs": {
+ "type": "string"
+ },
+ "en": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "cs",
+ "en"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "key",
+ "slug",
+ "title"
+ ],
+ "type": "object"
+ },
+ "disclaimer": {
+ "type": "string"
+ },
+ "generated": {
+ "type": "string"
+ },
+ "license": {
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "attribution"
+ ],
+ "type": "object"
+ },
+ "rails": {
+ "items": {
+ "properties": {
+ "arrivals": {
+ "description": "arrival airports RECORDED; covers_all_published_prices is false",
+ "type": "object"
+ },
+ "latest_stale_after_days": {
+ "description": "this rail's own freshness boundary, in days after measured.to",
+ "type": "number"
+ },
+ "measured": {
+ "properties": {
+ "days": {
+ "type": "integer"
+ },
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "days",
+ "from",
+ "to"
+ ],
+ "type": "object"
+ },
+ "origins": {
+ "description": "departure-airport CLUSTER; covers_all_published_prices is false",
+ "type": "object"
+ },
+ "party": {
+ "properties": {
+ "adults": {
+ "type": "integer"
+ },
+ "children": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "adults",
+ "children"
+ ],
+ "type": "object"
+ },
+ "price_covers": {
+ "description": "what the money buys - airfare only, or a package as offered",
+ "type": "object"
+ },
+ "rail": {
+ "enum": [
+ "flight",
+ "package"
+ ],
+ "type": "string"
+ },
+ "regime_breaks": {
+ "description": "[from, to] date spans where the series was not comparable",
+ "type": "array"
+ },
+ "resort": {
+ "type": "string"
+ },
+ "resort_key": {
+ "type": "string"
+ },
+ "searched": {
+ "description": "the search mode (and fixed dates, where there are any) the series was collected under",
+ "type": "object"
+ },
+ "stats": {
+ "properties": {
+ "basis": {
+ "type": "string"
+ },
+ "cheaper_than_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "is_series_max": {
+ "type": "boolean"
+ },
+ "is_series_min": {
+ "type": "boolean"
+ },
+ "latest": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "median": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "min": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "basis"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "rail",
+ "party",
+ "price_covers",
+ "measured",
+ "stats"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "resolved_from": {
+ "description": "Present when the caller named a RESORT key; the answer is its parent destination.",
+ "properties": {
+ "asked": {
+ "type": "string"
+ },
+ "resort": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "resort_key": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "asked",
+ "resort_key",
+ "resort"
+ ],
+ "type": "object"
+ },
+ "schema": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "schema",
+ "generated",
+ "destination",
+ "url",
+ "currency",
+ "license",
+ "rails",
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "tool-level failure, returned with isError: true",
+ "properties": {
+ "error": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}find_opportunities1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "currency": {
+ "type": "string"
+ },
+ "disclaimer": {
+ "type": "string"
+ },
+ "excluded": {
+ "items": {
+ "properties": {
+ "destination": {
+ "type": "string"
+ },
+ "history_days": {
+ "type": "integer"
+ },
+ "rail": {
+ "enum": [
+ "flight",
+ "package"
+ ],
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "resort_key": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "destination",
+ "rail",
+ "reason",
+ "history_days"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "generated": {
+ "description": "the OLDEST `generated` among the rows returned",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "license": {
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "attribution"
+ ],
+ "type": "object"
+ },
+ "matched": {
+ "description": "rows before the `limit` cap",
+ "type": "integer"
+ },
+ "min_history_days": {
+ "type": "integer"
+ },
+ "opportunities": {
+ "items": {
+ "properties": {
+ "cheaper_than_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "destination": {
+ "type": "string"
+ },
+ "generated": {
+ "type": "string"
+ },
+ "history_days": {
+ "type": "integer"
+ },
+ "is_series_min": {
+ "type": "boolean"
+ },
+ "latest": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "latest_cheaper_than_pct_of_days": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "latest_stale_after_days": {
+ "type": "number"
+ },
+ "measured": {
+ "properties": {
+ "days": {
+ "type": "integer"
+ },
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "days",
+ "from",
+ "to"
+ ],
+ "type": "object"
+ },
+ "median": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "min": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "party": {
+ "properties": {
+ "adults": {
+ "type": "integer"
+ },
+ "children": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "adults",
+ "children"
+ ],
+ "type": "object"
+ },
+ "rail": {
+ "enum": [
+ "flight",
+ "package"
+ ],
+ "type": "string"
+ },
+ "resort": {
+ "type": "string"
+ },
+ "resort_key": {
+ "type": "string"
+ },
+ "title": {
+ "properties": {
+ "cs": {
+ "type": "string"
+ },
+ "en": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "cs",
+ "en"
+ ],
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "destination",
+ "title",
+ "url",
+ "rail",
+ "party",
+ "latest",
+ "median",
+ "min",
+ "cheaper_than_pct",
+ "latest_cheaper_than_pct_of_days",
+ "is_series_min",
+ "history_days",
+ "measured",
+ "generated"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "schema": {
+ "type": "string"
+ },
+ "sort": {
+ "enum": [
+ "cheapest_vs_history",
+ "most_below_median"
+ ],
+ "type": "string"
+ },
+ "stale_rails": {
+ "description": "How many of the rails in scope are past their own freshness boundary on `as_of` (Europe/Prague).",
+ "properties": {
+ "as_of": {
+ "type": "string"
+ },
+ "count": {
+ "type": "integer"
+ },
+ "keys": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "of": {
+ "type": "integer"
+ },
+ "unknown": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "as_of",
+ "of",
+ "count",
+ "keys"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "schema",
+ "generated",
+ "sort",
+ "min_history_days",
+ "matched",
+ "stale_rails",
+ "opportunities",
+ "excluded",
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "tool-level failure, returned with isError: true",
+ "properties": {
+ "error": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}list_destinations1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "currency": {
+ "type": "string"
+ },
+ "destinations": {
+ "items": {
+ "properties": {
+ "generated": {
+ "type": "string"
+ },
+ "key": {
+ "type": "string"
+ },
+ "rails": {
+ "items": {
+ "properties": {
+ "measured": {
+ "properties": {
+ "days": {
+ "type": "integer"
+ },
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "days",
+ "from",
+ "to"
+ ],
+ "type": "object"
+ },
+ "party": {
+ "properties": {
+ "adults": {
+ "type": "integer"
+ },
+ "children": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "adults",
+ "children"
+ ],
+ "type": "object"
+ },
+ "rail": {
+ "enum": [
+ "flight",
+ "package"
+ ],
+ "type": "string"
+ },
+ "resort": {
+ "type": "string"
+ },
+ "resort_key": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "rail",
+ "party",
+ "measured"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "properties": {
+ "cs": {
+ "type": "string"
+ },
+ "en": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "cs",
+ "en"
+ ],
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "key",
+ "slug",
+ "title",
+ "url",
+ "generated",
+ "rails"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "disclaimer": {
+ "type": "string"
+ },
+ "license": {
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "attribution"
+ ],
+ "type": "object"
+ },
+ "schema": {
+ "type": "string"
+ },
+ "stale_rails": {
+ "description": "How many of the rails in scope are past their own freshness boundary on `as_of` (Europe/Prague).",
+ "properties": {
+ "as_of": {
+ "type": "string"
+ },
+ "count": {
+ "type": "integer"
+ },
+ "keys": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "of": {
+ "type": "integer"
+ },
+ "unknown": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "as_of",
+ "of",
+ "count",
+ "keys"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "schema",
+ "currency",
+ "count",
+ "stale_rails",
+ "destinations",
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "tool-level failure, returned with isError: true",
+ "properties": {
+ "error": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}price_history1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "currency": {
+ "type": "string"
+ },
+ "destination": {
+ "properties": {
+ "key": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "properties": {
+ "cs": {
+ "type": "string"
+ },
+ "en": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "cs",
+ "en"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "key",
+ "slug",
+ "title"
+ ],
+ "type": "object"
+ },
+ "disclaimer": {
+ "type": "string"
+ },
+ "generated": {
+ "type": "string"
+ },
+ "license": {
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "attribution"
+ ],
+ "type": "object"
+ },
+ "note": {
+ "description": "present when the `rail` filter matched nothing published for this destination",
+ "type": "string"
+ },
+ "rails": {
+ "items": {
+ "properties": {
+ "arrivals": {
+ "description": "arrival airports RECORDED; covers_all_published_prices is false",
+ "type": "object"
+ },
+ "latest_stale_after_days": {
+ "description": "this rail's own freshness boundary, in days after measured.to",
+ "type": "number"
+ },
+ "measured": {
+ "properties": {
+ "days": {
+ "type": "integer"
+ },
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "days",
+ "from",
+ "to"
+ ],
+ "type": "object"
+ },
+ "origins": {
+ "description": "departure-airport CLUSTER; covers_all_published_prices is false",
+ "type": "object"
+ },
+ "party": {
+ "properties": {
+ "adults": {
+ "type": "integer"
+ },
+ "children": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "adults",
+ "children"
+ ],
+ "type": "object"
+ },
+ "price_covers": {
+ "description": "what the money buys - airfare only, or a package as offered",
+ "type": "object"
+ },
+ "rail": {
+ "enum": [
+ "flight",
+ "package"
+ ],
+ "type": "string"
+ },
+ "regime_breaks": {
+ "description": "[from, to] date spans where the series was not comparable",
+ "type": "array"
+ },
+ "resort": {
+ "type": "string"
+ },
+ "resort_key": {
+ "type": "string"
+ },
+ "searched": {
+ "description": "the search mode (and fixed dates, where there are any) the series was collected under",
+ "type": "object"
+ },
+ "series_sample": {
+ "description": "a DOWNSAMPLED sample; `complete` says whether it is the whole series",
+ "properties": {
+ "complete": {
+ "type": "boolean"
+ },
+ "points": {
+ "items": {
+ "properties": {
+ "cheapest_total": {
+ "type": "number"
+ },
+ "date": {
+ "type": "string"
+ },
+ "departure": {
+ "type": "string"
+ },
+ "origin": {
+ "type": "string"
+ },
+ "return": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "date",
+ "cheapest_total"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "complete",
+ "points"
+ ],
+ "type": "object"
+ },
+ "stats": {
+ "properties": {
+ "basis": {
+ "type": "string"
+ },
+ "cheaper_than_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "is_series_max": {
+ "type": "boolean"
+ },
+ "is_series_min": {
+ "type": "boolean"
+ },
+ "latest": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "median": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "min": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "basis"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "rail",
+ "party",
+ "price_covers",
+ "measured",
+ "stats",
+ "series_sample"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "resolved_from": {
+ "description": "Present when the caller named a RESORT key; the answer is its parent destination.",
+ "properties": {
+ "asked": {
+ "type": "string"
+ },
+ "resort": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "resort_key": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "asked",
+ "resort_key",
+ "resort"
+ ],
+ "type": "object"
+ },
+ "schema": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "schema",
+ "generated",
+ "destination",
+ "url",
+ "currency",
+ "license",
+ "rails",
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "tool-level failure, returned with isError: true",
+ "properties": {
+ "error": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}current_vs_history1 field changedInput schema / properties / destination / descriptionPrevious value: -"destination slug"New value: +"destination slug, as returned by list_destinations. A RESORT key read off a rail (e.g. 'hurghada') also resolves, to its parent destination, and the answer then carries `resolved_from`; underscores and hyphens are interchangeable."price_history1 field changedInput schema / properties / destination / descriptionPrevious value: -"destination slug, as returned by list_destinations"New value: +"destination slug, as returned by list_destinations. A RESORT key read off a rail (e.g. 'hurghada') also resolves, to its parent destination, and the answer then carries `resolved_from`; underscores and hyphens are interchangeable."compare_destinationsfind_opportunitiescurrent_vs_historylist_destinationsprice_historyRealtime package holiday and charter flight prices from Sweden. Inventory not on Google Flights.
Prague apartment prices from the Czech land registry: median CZK/m2 by district, estimates, rankings
Flight search, airfare analytics, flexible destinations
Realtime package holiday and charter flight prices from Finland. Inventory not on Google Flights.
Add one secure layer between your agents and this server.
