Seatac Connection rides

Compare SEA parking vs a ride

compare_parking_vs_ride

Read-onlyIdempotent

Compare parking at the Seatac (SEA) airport garage for a trip with a round-trip private ride to and from the airport, using the same numbers as seatac.co/parking: Port of Seattle drive-up rates (taxes included) against example sedan fares from seven Seattle-area starting points. Returns both totals, which is cheaper and by how much, and the trip length where the ride starts winning. Optional: pass address + pickup_datetime for a live fare (one rate-limited quote).

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": {
      "days": "<days>"
    },
    "name": "compare_parking_vs_ride"
  }
}

Input Schema

Name	Required	Description
`bags`	No	Checked-size bags for the live fare (0-12, default 2).
`days`	Yes	Days the car would be parked (whole 24-hour days, 1-60).
`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.
`from_area`	No	Where the traveler drives from (default downtown-seattle).
`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.

Output Schema

Name	Required	Description
`trip`	No
`error`	No
`cheaper`	No
`verdict`	No
`page_url`	No
`private_ride`	No
`airport_garage`	No
`breakeven_days`	No	Trip length (days) from which the ride costs less than the garage.
`difference_usd`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds value beyond the readOnly/idempotent annotations by disclosing the cost model behind the numbers and warning that the live-fare path consumes one rate-limited quote. The rate-limit detail is exactly the kind of operational context annotations don't carry. Minor gap: no note on what happens if the live quote fails or is exhausted.

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?

Front-loads the core comparison and its data sources, then appends the optional live-fare mode at the end where the reader expects conditional behavior. Dense but nearly every clause carries information; the seatac.co/parking reference is the only mildly expendable detail.

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 an output schema present, return values needn't be spelled out, yet the description still names the outputs (both totals, delta, break-even trip length), which is sufficient for an agent to know the tool answers the question asked. Nothing critical is missing for a read-only comparison tool.

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 both parameters are already fully documented; baseline is 3. The description adds the pairing constraint that address and pickup_datetime must be used together for the live fare, but otherwise mostly restates what the schema already says.

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 SEA garage parking vs a round-trip private ride) and binds the comparison to a concrete cost model (Port of Seattle drive-up rates vs example sedan fares). This clearly separates it from siblings like compare_rental_vs_ride and compare_airport_options.

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?

Explains the two modes of use clearly: the default example-fare comparison, and the optional live-fare path via address + pickup_datetime. It doesn't explicitly state when to pick a sibling (e.g. quote_ride or compare_rental_vs_ride) instead, so a 5 isn't warranted.

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?