SlickTrip

Cheapest places to go

explore_destinations

Read-onlyIdempotent

Use when the traveler wants the cheapest place to fly from somewhere, or ideas for where to go, instead of a destination they already chose: "the cheapest flight from Warsaw, anywhere", "where can I go cheaply", "the cheapest city in Brazil". Returns destinations cheapest first with the airline, stops and a search_url: priced on the traveler's dates when you give depart_date (and return_date for a round trip), else each on its own cheapest dates in the coming months.

Input Schema

Name	Required	Description	Default
`cabin`	No	Cabin class.	economy
`abroad`	No	Only places outside the origin's country, when the traveler says out of the country, abroad or international.
`origin`	Yes	A 3-letter airport code (JFK), or a city code that searches every airport in the city (SlickTrip's 4-letter codes: NYCA New York, LOND London, ROME Rome, TYOA Tokyo). Up to 3 places joined with _ search them together (JFK_EWR). A place name works when one place clearly matches; otherwise the result is an unknown_place error listing suggestions. When the traveler names a city rather than an airport, send the city (its name or code), not one of its airports: one airport can miss the cheapest or the only flights. Unsure of the code: call find_places.
`nonstop`	No	Nonstop flights only.
`travelers`	No	Travelers who need a seat (adults and children). Fares are quoted for all of them together; one booking holds up to 9 (a larger group gets a suggested split). A baby under 2 on a lap is not a seat and is not counted here.
`trip_type`	No	Round trip or one way.	roundtrip
`depart_date`	No	YYYY-MM-DD: price every place on this day (the traveler's own). Empty: each on its own cheapest dates.
`max_results`	No	How many destinations to list.
`return_date`	No	YYYY-MM-DD, with depart_date, for a round trip.
`user_request`	No	Optional, and it works in the traveler's favor. Quote the traveler's latest message about this trip exactly as they wrote it, in their wording, language and spelling, not a summary. SlickTrip runs its own travel parser on these words: when a search fails or comes back empty, it compares what the traveler said with the arguments sent and returns a corrected search, so you can fix it without asking them again. It has caught Cancun sent as MEX instead of CUN, and travelers dropped from the party. A summary loses exactly the details it checks. If the message only answers a question ("yes, the 20th"), quote the message where they asked for the trip. Send the same quote on every call for this request. Leave out anything not about the trip, and never include names, contact details, or payment or ID information. The words also help SlickTrip improve its search.
`max_price_usd`	No	Only fares at or under this total, in US dollars.
`country_or_region`	No	Only destinations in this country or region, as the traveler said it.

Output Schema

Name	Required	Description
`code`	No	On an error: a machine-readable kind, e.g. unknown_place
`note`	No	How to read and use the list
`field`	No	On unknown_place: which argument (origin, destination, ...)
`search`	No	origin, trip_type, travelers, cabin, nonstop, country_or_region, max_price_usd
`status`	No	ok \| no_data \| error \| sign_in_required
`message`	No	What went wrong, when status is error
`suggestions`	No	On unknown_place: places to offer the traveler, each with code, name, kind (airport, all airports in the city, nearby airport), city, country
`total_found`	No	Destinations that fit, before max_results
`destinations`	No	city, country, airport, price_usd (total), per_traveler_usd, depart_date, return_date, airline, stops, duration_minutes, search_url
`places_assumed`	No	Place names this call resolved on its own, e.g. 'Portland = Portland, OR (PDX)'; tell the traveler

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 22, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the return shape (cheapest first, airline, stops, search_url) and the pricing mode switch (traveler's exact dates vs each destination's own cheapest dates). It stops short of covering pagination or rate-limit behavior, which is minor here.

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?

Two tightly written sentences, front-loaded with the use case and examples, then the return/pricing behavior. Every clause carries information the agent needs; nothing is repeated from the schema or annotations.

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 a 12-parameter schema with full descriptions, rich annotations, and an output schema, the description is nearly complete: it establishes purpose, usage, return content, and the key date-driven pricing behavior. It does not mention notable optional controls like max_price_usd or user_request, but those are thoroughly documented in the schema and output schema is present, so the omission is small.

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 100%, so the baseline is 3. The description earns an extra point by explaining the semantic consequence of depart_date/return_date: when supplied, all destinations are priced on those dates; when omitted, each destination is priced on its own cheapest dates in the coming months. That is genuine meaning beyond the schema text.

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 states a specific verb+resource ('cheapest place to fly from somewhere', 'ideas for where to go') and explicitly scopes it as an alternative to a trip where the destination is already chosen. The concrete example utterances make the purpose unmistakable without requiring the schema.

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 clearly defines when to use this tool ('the traveler wants the cheapest place to fly from somewhere... instead of a destination they already chose') and backs it with realistic traveler quotes. It does not name the sibling alternative (search_flights) explicitly, so the when-not is implied rather than enumerated.

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

All SlickTrip tools Inspect

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

Need Help?