Seatac Connection rides

Compare ways to and from SEA

compare_airport_options

Read-onlyIdempotent

Compare every way to get between Seatac Airport (SEA) and a Seattle-area place for one trip: a private Seatac Connection ride, driving and parking at the SEA garage, a rental car, app rideshare or taxi, and Link light rail. Priced options carry real numbers (Port of Seattle garage rates, typical rental costs, example or live ride fares); rideshare and light rail are described, not priced, because their prices are not fixed. direction: "departing" (flying out of SEA: the alternative is parking), "arriving" (visiting: the alternative is a rental), or "both". Ranks the priced options cheapest first.

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": {
      "trip_days": "<trip_days>"
    },
    "name": "compare_airport_options"
  }
}

Input Schema

Name	Required	Description
`area`	No	Seattle-area place the trip starts or ends at (default downtown-seattle).
`bags`	No	Checked-size bags for the live fare (0-12, default 2).
`address`	No	Optional exact pickup/drop-off address in the Seattle area for a live fare instead of the stored example fare, e.g. "1301 5th Ave, Seattle". Needs pickup_datetime. Uses one rate-limited live quote.
`direction`	No	departing = a local flying out of SEA (compare parking); arriving = a visitor flying in (compare a rental); both (default).
`trip_days`	Yes	Length of the trip in days (1-30): days parked, or nights in town for a rental.
`passengers`	No	Passengers for the live fare (1-12, default 2).
`pickup_datetime`	No	With address: the ride's pickup date and time, ISO 8601, Seattle local time when no offset, e.g. 2026-11-02T14:30.
`rental_daily_rate`	No	Optional: the traveler's own daily rental rate before tax, USD.

Output Schema

Name	Required	Description	Default
`trip`	No
`error`	No
`pages`	No
`options`	No
`ranking`	No
`cheapest_priced`	No
`parking_breakeven_days`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already establish read-only, idempotent behavior, but the description adds meaningful behavioral detail: priced options carry real numbers from specific sources, rideshare and light rail are described rather than priced because their prices are not fixed, and priced options are ranked cheapest first.

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 description is front-loaded with the comparison scope and mode list, then moves to direction semantics and ranking. It is dense and semicolon-heavy but every sentence carries useful information; there is little filler.

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?

Given a complex eight-parameter tool with an output schema and full schema coverage, the description supplies the key context an agent needs: what is compared, which options are priced versus described, and how results are ranked. Missing sibling routing is minor because direction semantics already frame the comparison scope.

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 eight parameters, including the direction enum and its meaning. The description restates the direction mapping but adds little syntax or format detail beyond what the schema provides, so baseline 3 is 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?

States a specific verb and resource: compare every way to get between SEA and a Seattle-area place. It enumerates the modes covered (private ride, parking, rental, rideshare/taxi, light rail), making clear this is the comprehensive comparison rather than a pairwise one.

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?

The direction values give clear usage contexts: departing implies comparing parking, arriving implies comparing a rental, and both is the default. It does not explicitly route the agent away from sibling tools like compare_parking_vs_ride or compare_rental_vs_ride, but the context is clear and not misleading.

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

All Seatac Connection rides 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?