Seatac Connection rides

Compare SEA rental car vs a ride

compare_rental_vs_ride

Read-onlyIdempotent

Compare renting a car at Seatac (SEA) for a stay with a private ride from the airport and back, as seatac.co/seatac-car-rental does: typical SEA daily rate, taxes and airport fees, the facility charge, and hotel parking every night (gas left out), against example sedan fares. Override the daily rate or hotel parking with the traveler's own quote. Returns the breakdown, which is cheaper, a ride booking link, and a rental search link (partner; seatac.co may earn a commission). Optional live fare with address + pickup_datetime (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": {
      "nights": "<nights>"
    },
    "name": "compare_rental_vs_ride"
  }
}

Input Schema

Name	Required	Description
`bags`	No	Checked-size bags for the live fare (0-12, default 2).
`nights`	Yes	Nights in town (1-30); the rental runs one day per night.
`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.
`passengers`	No	Passengers for the live fare (1-12, default 2).
`start_date`	No	Optional rental pickup date (YYYY-MM-DD) for the rental search link.
`staying_in`	No	Where the traveler stays (default downtown-seattle).
`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.
`hotel_parking_per_night`	No	Optional: the hotel's overnight parking per night, USD.

Output Schema

Name	Required	Description	Default
`trip`	No
`error`	No
`cheaper`	No
`verdict`	No
`page_url`	No
`rental_car`	No
`private_ride`	No
`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?

Annotations already declare readOnly/idempotent/closed-world, so the bar is lower, but the description still adds real context: the cost model (gas excluded, taxes/fees/facility charge included), a partner-commission disclosure, and that live fares consume one rate-limited quote. That is genuine behavioral detail beyond structured fields.

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 comparison scope and cost model are front-loaded and no sentence is filler, but the single dense paragraph with stacked parentheticals is harder to scan than it needs to be.

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 9 parameters and an output schema present, the description supplies the cost methodology and the live-vs-example fare distinction an agent needs to call it correctly. Return values are covered by the output schema, so nothing essential is missing, though the choice between compare_parking_vs_ride and this tool could be spelled out.

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 every parameter including ranges and defaults. The description only reinforces the rate override and the address + pickup_datetime dependency, both of which the schema already states, 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?

The description states a specific verb and two concrete resources (renting a car at SEA vs a private ride), and names the exact cost components it compares. It is clearly distinguishable from siblings such as compare_parking_vs_ride and quote_ride.

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 gives a clear usage context – a stay of N nights with airport rides both ways – and explains when to override the defaults with the traveler's own quote. It does not explicitly exclude scenarios or name a sibling alternative (e.g. quote_ride for a bare fare), so it falls short of full routing guidance.

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?