Skip to main content
Glama

Seatac Connection rides

Plan a Seattle trip

plan_seattle_trip
Read-onlyIdempotent

Plan a Seattle visit day by day, the same plan as seatac.co/seattle-trip-planner: a work trip, seeing family, a game or concert, or a holiday (for a cruise use plan_cruise_trip). Give the dates; everything else is optional and can be added on later calls. Returns each day in order: arrival (flight, the Seatac ride with its pickup time and estimate), the hotel, each day's plan from morning to evening with meetings at their set times, meals, experiences and events, the estimated travel time between stops and a ride link for each leg, warnings when something won't fit, suggested restaurants and experiences for empty parts of the day, games and concerts on each date with ticket links, the ride back to the airport timed from the flight home, hotel options ranked for the trip (nearest the meetings for work), an estimated total, and plan_page_url, which opens exactly this plan for the traveler to change and book. Nothing is assumed booked. Read-only; no payment.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "start": "<start>"
    },
    "name": "plan_seattle_trip"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoDay they leave, YYYY-MM-DD (same as start for a day trip). Or give nights.
picksNoThings to put on the plan (up to 30): a pick_id from suggestions, events, find_things_to_do or find_restaurants, a date, and optionally the part of the day.
startYesDay they arrive in Seattle, YYYY-MM-DD.
nightsNoNights in Seattle instead of end (0-21, default 2).
purposeNoWhat the trip is for: business, visit, event, vacation or other. Business ranks hotels by the meetings and defaults to 1 traveler.
meetingsNoMeetings or appointments at set times (up to 10).
arrive_byNofly (default), drive, train (King Street Station), bus, ferry (Colman Dock or Pier 69), or other.
hotel_nameNoOr a hotel they booked elsewhere, "name, address".
hotel_slugNoOne of our hotels (slug from hotel_options).
party_sizeNoTravelers (1-14; default 1 for business, else 2).
suggestionsNoSuggest restaurants and experiences for empty parts of each day (default true).
home_airportNo3-letter code of the airport they fly from, e.g. ORD.
landing_timeNoLanding time at Seatac, Seattle time HH:MM. Sets the airport pickup and the first afternoon.
arrival_placeNotrain, bus, ferry or other: where they arrive (a bus stop, a ferry terminal). Defaults: King Street Station for the train, Colman Dock for the ferry.
return_flightNoFlight home, e.g. AS 38.
arrival_flightNoArriving flight number, e.g. AS 33.
departure_timeNoFlight home's departure, Seattle time HH:MM. Sets the last day and the ride to the airport.

Output Schema

NameRequiredDescriptionDefault
costNo
daysNo
tripNo
errorNo
hotel_optionsNo
plan_page_urlNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / arrival_place / description
      Previous value: -"train_bus_ferry: where they arrive, e.g. King Street Station."New value: +"train, bus, ferry or other: where they arrive (a bus stop, a ferry terminal). Defaults: King Street Station for the train, Colman Dock for the ferry."
    • changedInput schema / properties / arrive_by / description
      Previous value: -"fly (default), drive, or train_bus_ferry."New value: +"fly (default), drive, train (King Street Station), bus, ferry (Colman Dock or Pier 69), or other."
    • changedInput schema / properties / arrive_by / enum
      Previous value: -[
      -  "fly",
      -  "drive",
      -  "train_bus_ferry"
      -]New value: +[
      +  "fly",
      +  "drive",
      +  "train",
      +  "bus",
      +  "ferry",
      +  "other",
      +  "train_bus_ferry"
      +]
    • changedInput schema / properties / purpose / description
      Previous value: -"What the trip is for: business, visit, event or vacation. Business ranks hotels by the meetings and defaults to 1 traveler."New value: +"What the trip is for: business, visit, event, vacation or other. Business ranks hotels by the meetings and defaults to 1 traveler."
    • changedInput schema / properties / purpose / enum
      Previous value: -[
      -  "business",
      -  "visit",
      -  "event",
      -  "vacation"
      -]New value: +[
      +  "business",
      +  "visit",
      +  "event",
      +  "vacation",
      +  "other"
      +]
  2. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with the substantive commitment "Nothing is assumed booked" and "no payment", which goes beyond what annotations say. It also discloses behavioral traits an agent needs: everything after the dates is optional and can be added on later calls, and plans may include warnings when something won't fit. It adds no rate-limit or failure-mode info, but none is critical here.

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?

Purpose and the cruise exclusion are front-loaded, which is right. But the bulk of the text is a single sprawling sentence enumerating every returned artifact, duplicating an output schema that already exists, which makes the description heavier than it needs to be for an agent to select and invoke the tool.

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 a full output schema and rich annotations, the description does not need to enumerate return values, yet it is otherwise complete: it covers purpose, incremental-call behavior, the no-booking guarantee, and the cruise hand-off. Only the sibling routing beyond plan_cruise_trip is under-specified.

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 baseline is 3. The description does clarify which inputs are the essential ones (dates) and that hotel_name is for hotels "booked elsewhere" versus hotel_slug for "our hotels", but most parameter meaning is already carried by the schema, and the remaining 15 parameters get no further elaboration in prose.

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 specific verb and resource ("Plan a Seattle visit day by day") and explicitly routes cruise planning to the sibling plan_cruise_trip. An agent can distinguish this from every other plan_* sibling 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 Guidelines4/5

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

Gives a clear entry condition ("Give the dates; everything else is optional and can be added on later calls") and names the one exclusion (cruises go to plan_cruise_trip). It also implies a workflow by noting picks come from suggestions, find_things_to_do, or find_restaurants, but it never states when to prefer plan_airport_departure, recommend_hotels_with_rides, or quote_ride instead of or before planning.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources