SlickTrip

Seat availability

seat_availability

Read-onlyIdempotent

Use to see which seats are open right now on one flight (needs a signed-in SlickTrip account; nothing is charged or changed): open seat numbers by row, counts of window, aisle, middle and exit-row seats, and rows with two seats together. Needs the flight number, route and date. Then track_seats to be told when a seat opens. Not for prices.

Input Schema

Name	Required	Description	Default
`cabin`	No	Cabin to look at; any = every cabin on the flight.	economy
`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.
`depart_date`	Yes	YYYY-MM-DD.
`destination`	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.
`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.
`flight_number`	Yes	Airline code and number, no space.

Output Schema

Name	Required	Description
`code`	No	On an error: a machine-readable kind, e.g. unknown_place
`note`	No	Use track_seats to be alerted
`cabin`	No	Cabin tier queried
`field`	No	On unknown_place: which argument (origin, destination, ...)
`counts`	No	seats, available, window, aisle, middle, exit_row, rows_with_2_together
`flight`	No	flight_number, origin, destination, departure_time, arrival_time, aircraft, airline
`status`	No	ok \| no_data \| error \| sign_in_required
`message`	No	No seat map explanation or wrapper error
`exit_rows`	No	Row numbers with exit-row seats
`seat_kinds`	No	Seat letter to window \| aisle \| middle
`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
`seat_map_svg`	No	url, view_box, aircraft, seats[] with x/y/w/h/status/kind
`seat_map_url`	No	slicktrip.com seat-tracker setup page link
`open_seat_ids`	No	Every open seat id in the cabin, space-separated
`places_assumed`	No	Place names this call resolved on its own, e.g. 'Portland = Portland, OR (PDX)'; tell the traveler
`taken_seat_ids`	No	Every taken seat id in the cabin, space-separated
`available_seats`	No	Items: seat, kind, exit_row (up to 80)
`seat_tracker_url`	No	slicktrip.com seat-tracker route link

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 9, 2026

changedInput schema / properties / destination / description

Previous value: -"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. Unsure of the code: call find_places."New value: +"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."

changedInput schema / properties / origin / description

Previous value: -"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. Unsure of the code: call find_places."New value: +"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."

changedInput schema / properties / user_request / anyOf

Previous value: -[
-  {
-    "maxLength": 300,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 500,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / user_request / description

Previous value: -"Optional. The traveler's current travel request, briefly, in their own words. Used to interpret this search, suggest a corrected search if it fails, and improve SlickTrip's search. Include only this request; not earlier conversation, names, contact details, or payment or ID information."New value: +"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."

changedInput schema / properties / user_request / examples

Previous value: -[
-  "cheap nonstop to Lisbon early May",
-  "family of 8 in Albufeira, 4 nights mid November"
-]New value: +[
+  "we're 6 friends from madrid, want somewhere cheap and fun in europe dec 20-24, morning flights pls",
+  "necesito llevar a mi mamá de Calgary a Kolkata a fines de octubre, no puede hacer escala en Estados Unidos"
+]

Changed4 schema fields changedOct 6, 2026

changedInput schema / properties / destination / description

Previous value: -"A 3-letter airport code (JFK), or a city code that searches every airport in the city (NYC, LON, ROM, TYO). Up to 3 airports 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. Unsure of the code: call find_places."New value: +"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. Unsure of the code: call find_places."

changedInput schema / properties / destination / examples

Previous value: -[
-  "JFK",
-  "ROM",
-  "JFK_EWR"
-]New value: +[
+  "JFK",
+  "NYCA",
+  "JFK_EWR"
+]

changedInput schema / properties / origin / description

Previous value: -"A 3-letter airport code (JFK), or a city code that searches every airport in the city (NYC, LON, ROM, TYO). Up to 3 airports 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. Unsure of the code: call find_places."New value: +"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. Unsure of the code: call find_places."

changedInput schema / properties / origin / examples

Previous value: -[
-  "JFK",
-  "ROM",
-  "JFK_EWR"
-]New value: +[
+  "JFK",
+  "NYCA",
+  "JFK_EWR"
+]

First observedOct 5, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is largely covered. The description still adds real context the annotations cannot: the account/auth requirement and the reassurance that 'nothing is charged or changed', plus the shape of what comes back.

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?

Four tight sentences, front-loaded with the purpose before the prerequisite and the routing note. It packs in a fair amount of detail about return contents, but no sentence is filler and the negative scoping ('Not for prices') lands last for emphasis.

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 read-only query tool with an output schema, a complete annotations set and 100% schema coverage, the description supplies everything an agent needs: auth prerequisite, what the result contains, the natural follow-up tool, and what the tool is not for.

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 parameters (including the detailed origin/destination code rules and the user_request quoting behavior) are already fully documented in the schema. The description only restates that flight number, route and date are needed, adding no syntax or format detail beyond it — the baseline 3 for schema-covered parameters.

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?

States a precise verb and resource with scope: 'see which seats are open right now on one flight'. It also distinguishes itself from siblings by naming track_seats as the follow-up and declaring 'Not for prices', so an agent can separate it from price_calendar, flight_lookup and list_tracked_seats without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the when ('see which seats are open right now'), the routing alternative ('Then track_seats to be told when a seat opens'), and an explicit exclusion ('Not for prices'). The only prerequisite, a signed-in SlickTrip account, is stated inline.

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?