Skip to main content
Glama

FareDice

by com.faredice
OverviewDiscussionsAdmin

Server Details

Cheap multi-country trips and non-stop fares by day in Europe and Southeast Asia

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.9% over 22 days
Last Tested
Transport
Streamable HTTP · MCP 2025-06-18
URL

TDQS

A3.6/5.0

Scored across 3 tools

Disambiguation4/5

The three tools target distinct tasks: multi-city trip planning, route-level fare history, and destination discovery from a city. The two nonstop_* tools share a prefix and both return fare data, but their inputs and outputs are clearly differentiated in the descriptions.

Naming Consistency3/5

find_trips uses a verb_noun pattern, while nonstop_fares and nonstop_from use an adjective_noun/preposition pattern; all are snake_case and readable, but the set lacks a single consistent convention.

Tool Count4/5

Three tools is on the low end but appropriate for a focused flight-fare discovery service; each tool has a distinct, substantial capability and there is no obvious redundancy.

Completeness4/5

The surface covers trip planning, route fare lookup, and destination discovery, including reverse-direction fares within nonstop_fares. Minor gaps exist, such as a dedicated tool for exploring fares to a specific city or for flexible multi-city date searches, but core workflows are covered.

Available Tools

3 tools
find_tripsFind cheap multi-country tripsA
Read-onlyIdempotent
Inspect

Finds cheap trips through several cities and countries in Europe or Southeast Asia, strung from non-stop one-way fares seen in the last few days: you give a start city (or a home airport outside the region: the trip then starts with a flight from the nearest big airport we have fares from), a window for the first flight, how many places and nights in each, and a flight budget, and optionally the kinds of place (beaches, islands, capitals ...), countries to keep to or skip and cities per country; it picks the cities. Returns the cheapest three trips, each with its flights, fare ages, cabin-bag notes and a link to the trip on faredice.com.

NameRequiredDescriptionDefault
endNohome: the last flight returns to the start city (with home, to the airport the trip flew in through). Default anywhere.
fromNoStart city: a name ("Lisbon") or IATA city code ("LIS"), "anywhere" to start in any of the region's busiest cities, or a country ("anywhere in Germany", "Spain") to start in any of its cities. Needed unless home is given.
homeNoThe traveller's home airport when it is outside the region: a town ("Calgary", "London, Ontario") or IATA code ("YYC"). Trips then start with a flight in from the nearest big airport we have fares from (Toronto, New York, Sydney ...), usually with a stop, and from there it's the same trip. The budget covers that flight; getting from home to that airport isn't in the prices. With home, from is used only when we can't fly from that home.
startNoEarliest day for the first flight, YYYY-MM-DD. Fares cover about the next 90 days. Default: a week from today.
untilNoLatest day for the first flight, YYYY-MM-DD. Default: two weeks after start.
regionNoWhere the trip goes. Default europe.
cabin_bagNotrue: the traveller takes a cabin bag (the wheeled one for the overhead locker), so the budget and the ranking count each flight's usual price for one where we know it; a flight whose bag price we don't know counts €35, the dearest bag price we know, so the total is an estimate (see unpriced_cabin_bags). Default false: fares alone.
countriesNoISO country codes ("ES", "PT"): every stop is in one of these.
passportsNoISO country codes of the traveller's passports ("US", "IN"): countries that need a visa in advance are left out.
visa_freeNoWith passports: only countries that need no visa of any kind, leaving out e-visas, ETAs and visas on arrival as well as visas needed before flying.
budget_eurNoMost to spend on all the flights, in euros, for all the travellers together (up to 5,000 each).
held_visasNoValid visas the traveller already holds, with passports: "schengen" opens the Schengen area (its days counted against 90 in any 180) and the countries outside it that admit Schengen visa holders; "uk" and "us" open the countries that admit holders of those. The traveller still checks the visa's own dates and entries.
nights_maxNoMost nights in each place.
nights_minNoFewest nights in each place.
places_maxNoMost places to stay in. Default 12, any number.
places_minNoFewest places to stay in. Default 4.
travellersNoHow many adults travel together. Default 1. Every price in the answer, and the budget, is then for all of them.
warm_min_cNoOnly places whose typical daytime high for the month of the stay is at least this many °C, from long-term weather station averages (a place without them is left out). For winter sun in Europe.
then_regionNoWith home: after region, fly on to this other region and home from there, in one trip (europe then southeast-asia, or the reverse). Three long flights: home into region, one across (from or to London or Paris), and home from then_region; each a separate ticket, all in the total and the budget. Homes: Vancouver or Los Angeles, or an airport within 1,000 km of them. The trip always ends home; places_min splits between the regions. A budget of about 2,000 euros fits most.
kinds_of_placeNoKinds of place, from our notes on each city: per kind, "only" (every stop is one), "none" (no stop is one) or at least n stops of it (1-4), e.g. {"beaches": 2, "capitals": "none"}. One kind can be "only". Ski counts only from December to mid-April, and only in Europe. The start and the return don't count as stops.
skip_countriesNoISO country codes to leave out of the trip.
cities_per_countryNoMost cities in any one country. Default 1; 0 for any number (answers write it "any").

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds real behavioral context beyond that: fares are 'seen in the last few days,' only the cheapest three trips come back, and results include flight details, fare ages, cabin-bag notes and a faredice.com link.

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 purpose is front-loaded in the opening clause and every subsequent clause maps to a real input or output concern. It is essentially one very long sentence with heavy sub-clause nesting, which is dense but justified given the 22-parameter surface, though it could be broken up for readability.

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 complex, fully-optional-parameter tool with no output schema, the description covers the workflow, the required-in-practice inputs, and the shape of the return (cheapest three trips with flights, fare ages, bag notes, link). Combined with the exhaustive schema, an agent has everything needed to invoke it correctly.

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?

Schema description coverage is 100%, so the schema already documents all 22 parameters thoroughly, including the nuance of home airports, visa/passport handling and the cabin-bag pricing caveat. The description summarizes the key inputs in prose but adds no syntax or format detail beyond the schema, making the baseline of 3 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 opens with a specific verb and resource ('Finds cheap trips through several cities and countries') and pins the scope to Europe or Southeast Asia, sourced from recent non-stop one-way fares. This distinguishes it from the sibling fare tools (nonstop_fares, nonstop_from) by making clear it assembles multi-city itineraries rather than retrieving individual fares.

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?

It lays out the inputs that drive the search (start city or home airport, flight window, places/nights, budget) and the optional refinements (kinds of place, countries to keep/skip, cities per country), which gives clear context for when this tool applies. It stops short of explicitly naming the sibling tools or stating when to prefer them over this one, so it is not a full 5.

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

nonstop_faresCheapest fare each day between two citiesA
Read-onlyIdempotent
Inspect

The cheapest one-way fare seen on each day of the next three months or so from one city to another in Europe or Southeast Asia (non-stop flights), or on a long flight between a big airport outside the region and one of its cities (any stops): each day's price, its age and airline, the cheapest by month, the airlines with how many days they fly it and their cabin bag rule, the cheapest the other way, and a link to the route's page on faredice.com.

NameRequiredDescriptionDefault
toYesA city by name ("Berlin", "Krakow", "Saigon") or IATA city code ("BER"). For a long flight, one end can be a big airport outside the region we have fares from (Vancouver, Toronto, New York, Sydney, London for Southeast Asia ...).
fromYesA city by name ("Berlin", "Krakow", "Saigon") or IATA city code ("BER"). For a long flight, one end can be a big airport outside the region we have fares from (Vancouver, Toronto, New York, Sydney, London for Southeast Asia ...).
monthNoOnly this month's days: YYYY-MM or a month's name ("november"). Default every day we have.
regionNoeurope or southeast-asia. Default: the first region where both places are found, Europe first.

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds substantive return-value context absent from structured fields: daily price, its age and airline, monthly cheapest, airline frequency and cabin bag rule, reverse cheapest, and a link. It still omits rate limits, error behavior, and exact data freshness beyond 'next three months or so'.

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 purpose is front-loaded in one dense sentence, and the colon-separated list efficiently enumerates return fields. The sentence is somewhat run-on and could be split for readability, but every clause earns its place given the absence of an output schema.

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?

With no output schema, the description adequately explains what the tool returns and its route scope. Parameter details are fully covered by the schema, and annotations cover safety, so the definition is nearly complete for correct invocation, though it lacks sibling routing guidance.

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?

Schema coverage is 100%, so all four parameters are already documented in the input schema. The description provides helpful route-type context (non-stop vs. long-haul any stops) but does not add syntax or defaults beyond what the schema already provides for from, to, month, and region.

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

Purpose4/5

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

The description states a specific resource (cheapest one-way fare per day between two cities) with clear scope conditions (Europe/Southeast Asia non-stop or long-haul any stops). It does not explicitly distinguish itself from the sibling tools find_trips or nonstop_from, so it falls short of a 5.

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?

Usage is implied by the route and time-horizon constraints, but there is no explicit guidance on when to choose this tool over find_trips or nonstop_from. The description does not name alternatives or state when-not-to-use.

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

nonstop_fromEvery city a city flies to non-stopB
Read-onlyIdempotent
Inspect

Every city one city in Europe or Southeast Asia flies to non-stop over the next three months or so (or that a big airport outside the region flies to, any stops), cheapest first: each with its cheapest fare, the day, its age and airline, how many days have fares and the airlines, and links to each route's page on faredice.com.

NameRequiredDescriptionDefault
fromYesA city by name ("Berlin", "Krakow", "Saigon") or IATA city code ("BER"). For a long flight, one end can be a big airport outside the region we have fares from (Vancouver, Toronto, New York, Sydney, London for Southeast Asia ...).
regionNoeurope or southeast-asia. Default: the first region where both places are found, Europe first.
max_resultsNoMost cities to list, cheapest first. Default 30.

TDQS

B3.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add operational context — it does, disclosing the ~3-month forward window and the cheapest-first ordering. It stops short of noting pagination/truncation behavior when capped by max_results.

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

Conciseness3/5

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

It is a single sentence with no filler, and the geographic scope is reasonably front-loaded. However, it crams origin scope, time window, sort order, and seven return fields into one dense clause, making it hard to parse on a first read.

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?

With no output schema, the description correctly carries the burden of describing return values: cheapest fare, day, age, airline, count of days with fares, airlines, and route links. Parameters and safety are fully covered elsewhere, so the main omission is any routing guidance toward the sibling tools.

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?

Schema description coverage is 100%, so the schema already explains from, region, and max_results. The description only echoes the region scope ('Europe or Southeast Asia') and the cheapest-first ordering implied by max_results, adding little beyond what the schema already documents.

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

Purpose3/5

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

The opening clause essentially restates the title ('Every city a city flies to non-stop') rather than stating a distinct verb+resource action. It does convey the underlying operation (enumerate non-stop destinations from one origin) but does so obliquely, buried under a list of return fields, and it never distinguishes itself from find_trips or nonstop_fares.

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?

There is no explicit when-to-use guidance and no comparison to the siblings find_trips and nonstop_fares, which appear to cover overlapping fare-search territory. The only selection cue is the implicit 'next three months or so' time window, which is stated as a data property, not as a usage condition.

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.

  1. 2 tool updates
    • Addednonstop_fares
    • Addednonstop_from
  2. 1 tool update
    • Changedfind_trips1 field changed
      • addedInput schema / properties / warm_min_c
        Added value: +{
+  "description": "Only places whose typical daytime high for the month of the stay is at least this many °C, from long-term weather station averages (a place without them is left out). For winter sun in Europe.",
+  "enum": [
+    16,
+    18,
+    20,
+    22,
+    25
+  ],
+  "type": "integer"
+}
  3. 1 tool update
    • Changedfind_trips2 fields changed
      • changedInput schema / properties / places_max / description
        Previous value: -"Most places to stay in."New value: +"Most places to stay in. Default 12, any number."
      • changedInput schema / properties / places_min / description
        Previous value: -"Fewest places to stay in."New value: +"Fewest places to stay in. Default 4."
  4. 1 tool update
    • Changedfind_trips1 field changed
      • addedInput schema / properties / visa_free
        Added value: +{
+  "description": "With passports: only countries that need no visa of any kind, leaving out e-visas, ETAs and visas on arrival as well as visas needed before flying.",
+  "type": "boolean"
+}
  5. 1 tool update
    • Changedfind_trips1 field changed
      • changedInput schema / properties / cities_per_country / description
        Previous value: -"Most cities in any one country. Default 1; 0 for any number."New value: +"Most cities in any one country. Default 1; 0 for any number (answers write it \"any\")."
  6. 1 tool update
    • Changedfind_trips4 fields changed
      • addedInput schema / properties / cities_per_country
        Added value: +{
+  "description": "Most cities in any one country. Default 1; 0 for any number.",
+  "maximum": 3,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / countries
        Added value: +{
+  "description": "ISO country codes (\"ES\", \"PT\"): every stop is in one of these.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 12,
+  "type": "array"
+}
      • addedInput schema / properties / kinds_of_place
        Added value: +{
+  "additionalProperties": false,
+  "description": "Kinds of place, from our notes on each city: per kind, \"only\" (every stop is one), \"none\" (no stop is one) or at least n stops of it (1-4), e.g. {\"beaches\": 2, \"capitals\": \"none\"}. One kind can be \"only\". Ski counts only from December to mid-April, and only in Europe. The start and the return don't count as stops.",
+  "properties": {
+    "beaches": {
+      "oneOf": [
+        {
+          "maximum": 4,
+          "minimum": 1,
+          "type": "integer"
+        },
+        {
+          "enum": [
+            "only",
+            "none"
+          ],
+          "type": "string"
+        }
+      ]
+    },
+    "capitals": {
+      "oneOf": [
+        {
+          "maximum": 4,
+          "minimum": 1,
+          "type": "integer"
+        },
+        {
+          "enum": [
+            "only",
+            "none"
+          ],
+          "type": "string"
+        }
+      ]
+    },
+    "islands": {
+      "oneOf": [
+        {
+          "maximum": 4,
+          "minimum": 1,
+          "type": "integer"
+        },
+        {
+          "enum": [
+            "only",
+            "none"
+          ],
+          "type": "string"
+        }
+      ]
+    },
+    "lakes": {
+      "oneOf": [
+        {
+          "maximum": 4,
+          "minimum": 1,
+          "type": "integer"
+        },
+        {
+          "enum": [
+            "only",
+            "none"
+          ],
+          "type": "string"
+        }
+      ]
+    },
+    "mountains": {
+      "oneOf": [
+        {
+          "maximum": 4,
+          "minimum": 1,
+          "type": "integer"
+        },
+        {
+          "enum": [
+            "only",
+            "none"
+          ],
+          "type": "string"
+        }
+      ]
+    },
+    "old_towns": {
+      "oneOf": [
+        {
+          "maximum": 4,
+          "minimum": 1,
+          "type": "integer"
+        },
+        {
+          "enum": [
+            "only",
+            "none"
+          ],
+          "type": "string"
+        }
+      ]
+    },
+    "ski": {
+      "oneOf": [
+        {
+          "maximum": 4,
+          "minimum": 1,
+          "type": "integer"
+        },
+        {
+          "enum": [
+            "only",
+            "none"
+          ],
+          "type": "string"
+        }
+      ]
+    },
+    "small_towns": {
+      "oneOf": [
+        {
+          "maximum": 4,
+          "minimum": 1,
+          "type": "integer"
+        },
+        {
+          "enum": [
+            "only",
+            "none"
+          ],
+          "type": "string"
+        }
+      ]
+    }
+  },
+  "type": "object"
+}
      • addedInput schema / properties / skip_countries
        Added value: +{
+  "description": "ISO country codes to leave out of the trip.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 20,
+  "type": "array"
+}
  7. 1 tool update
    • Changedfind_trips3 fields changed
      • changedInput schema / properties / budget_eur / description
        Previous value: -"Most to spend on all the flights, in euros."New value: +"Most to spend on all the flights, in euros, for all the travellers together (up to 5,000 each)."
      • changedInput schema / properties / budget_eur / maximum
        Previous value: -5000New value: +30000
      • addedInput schema / properties / travellers
        Added value: +{
+  "description": "How many adults travel together. Default 1. Every price in the answer, and the budget, is then for all of them.",
+  "maximum": 6,
+  "minimum": 1,
+  "type": "integer"
+}
  8. 1 tool update
    • Changedfind_trips1 field changed
      • addedInput schema / properties / then_region
        Added value: +{
+  "description": "With home: after region, fly on to this other region and home from there, in one trip (europe then southeast-asia, or the reverse). Three long flights: home into region, one across (from or to London or Paris), and home from then_region; each a separate ticket, all in the total and the budget. Homes: Vancouver or Los Angeles, or an airport within 1,000 km of them. The trip always ends home; places_min splits between the regions. A budget of about 2,000 euros fits most.",
+  "enum": [
+    "europe",
+    "southeast-asia"
+  ],
+  "type": "string"
+}
  9. 1 tool update
    • Changedfind_trips1 field changed
      • changedInput schema / properties / cabin_bag / description
        Previous value: -"true: the traveller takes a cabin bag (the wheeled one for the overhead locker), so the budget and the ranking count each flight's usual price for one where we know it; a flight whose bag price we don't know counts at its fare (see unpriced_cabin_bags). Default false: fares alone."New value: +"true: the traveller takes a cabin bag (the wheeled one for the overhead locker), so the budget and the ranking count each flight's usual price for one where we know it; a flight whose bag price we don't know counts €35, the dearest bag price we know, so the total is an estimate (see unpriced_cabin_bags). Default false: fares alone."
  10. 1 tool update
    • Changedfind_trips1 field changed
      • addedInput schema / properties / cabin_bag
        Added value: +{
+  "description": "true: the traveller takes a cabin bag (the wheeled one for the overhead locker), so the budget and the ranking count each flight's usual price for one where we know it; a flight whose bag price we don't know counts at its fare (see unpriced_cabin_bags). Default false: fares alone.",
+  "type": "boolean"
+}
  11. 1 tool update
    • Changedfind_trips1 field changed
      • addedInput schema / properties / held_visas
        Added value: +{
+  "description": "Valid visas the traveller already holds, with passports: \"schengen\" opens the Schengen area (its days counted against 90 in any 180) and the countries outside it that admit Schengen visa holders; \"uk\" and \"us\" open the countries that admit holders of those. The traveller still checks the visa's own dates and entries.",
+  "items": {
+    "enum": [
+      "schengen",
+      "uk",
+      "us"
+    ],
+    "type": "string"
+  },
+  "maxItems": 3,
+  "type": "array"
+}
  12. 1 tool update
    • Changedfind_trips1 field changed
      • changedInput schema / properties / from / description
        Previous value: -"Start city: a name (\"Lisbon\") or IATA city code (\"LIS\"), or \"anywhere\" to start in any of the region's busiest cities. Needed unless home is given."New value: +"Start city: a name (\"Lisbon\") or IATA city code (\"LIS\"), \"anywhere\" to start in any of the region's busiest cities, or a country (\"anywhere in Germany\", \"Spain\") to start in any of its cities. Needed unless home is given."
  13. 1 tool update
    • Changedfind_trips4 fields changed
      • changedInput schema / properties / end / description
        Previous value: -"home: the last flight returns to the start city. Default anywhere."New value: +"home: the last flight returns to the start city (with home, to the airport the trip flew in through). Default anywhere."
      • changedInput schema / properties / from / description
        Previous value: -"Start city: a name (\"Lisbon\") or IATA city code (\"LIS\"), or \"anywhere\" to start in any of the region's busiest cities."New value: +"Start city: a name (\"Lisbon\") or IATA city code (\"LIS\"), or \"anywhere\" to start in any of the region's busiest cities. Needed unless home is given."
      • addedInput schema / properties / home
        Added value: +{
+  "description": "The traveller's home airport when it is outside the region: a town (\"Calgary\", \"London, Ontario\") or IATA code (\"YYC\"). Trips then start with a flight in from the nearest big airport we have fares from (Toronto, New York, Sydney ...), usually with a stop, and from there it's the same trip. The budget covers that flight; getting from home to that airport isn't in the prices. With home, from is used only when we can't fly from that home.",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "from"
-]New value: +[]
  14. 1 tool update
    • First observedfind_trips

Related MCP Connectors

Related MCP Servers

  • google-flights-mcp

    mtnrabi
    A
    license
    A
    quality
    B
    maintenance
    Enables real-time flight fare searches across date ranges and multiple destinations, with historical price insights and booking links. Provides one-way and round-trip search tools through MCP.
    4
    1
    MIT

  • rihla

    leojg
    A
    license
    Not graded
    quality
    C
    maintenance
    Flexible multi-leg, multi-airport flight search that finds the cheapest route across an entire itinerary — available as a CLI and as an MCP server for AI agents.
    Apache 2.0

  • cheapdates-mcp

    afgoes
    A
    license
    A
    quality
    B
    maintenance
    Enables users to find the cheapest dates to fly a route via Google Flights, supporting one-way and round-trip searches through multiple backends. It provides a tool that can search date ranges, filter by nonstop, seat, currency, and force a particular backend.
    1
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources