Seatac Connection rides

Hotels with whole-trip ride costs

recommend_hotels_with_rides

Read-onlyIdempotent

Recommend Seattle hotels for a stay with the whole-trip cost: typical room rate for the nights plus the rides the stay needs (Seatac → hotel on check-in day, then hotel → cruise pier or back to Seatac on check-out day). near is a cruise pier (pier-66, pier-91: check-out day is sailing day) or a hotel area. For a pier it also prices a SeaTac airport hotel, so the traveler can see when a cheaper airport room plus rides beats a downtown room. Room links lead; ride links are the add-on. Typical rates and ride estimates, not live prices.

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": {
      "near": "<near>",
      "checkin": "<checkin>",
      "checkout": "<checkout>"
    },
    "name": "recommend_hotels_with_rides"
  }
}

Input Schema

Name	Required	Description
`near`	Yes	A cruise pier (pier-66, pier-91) or a hotel area.
`limit`	No	Hotels to return (1-8, default 5).
`checkin`	Yes	Check-in date, YYYY-MM-DD.
`checkout`	Yes	Check-out date, YYYY-MM-DD (sailing day for a pier).
`party_size`	No	Travelers (1-14, default 2).
`compare_airport_hotel`	No	For a pier: also price a SeaTac airport hotel (default true).

Output Schema

Name	Required	Description	Default
`stay`	No
`error`	No
`hotels`	No
`insight`	No
`page_url`	No
`airport_hotel_alternative`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses that costs combine typical room rates with ride estimates, that prices are not live, that room links are primary and ride links are add-ons, and that pier searches include an airport-hotel comparison. These are substantive behavioral details an agent would not get from the annotations or schema alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core recommendation and cost formula, then efficiently covers input semantics, comparison behavior, link priority, and the estimate caveat. Every sentence carries useful information and there is no 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 the tool's complexity, six parameters, output schema, and read-only annotations, the description supplies the key context an agent needs: what is priced, how piers change the comparison, what the returned links mean, and that rates are estimates rather than live quotes. It does not need to repeat return-value structure because an output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3, but the description adds useful meaning: it explains how near relates to piers versus hotel areas, that checkout is the sailing day for a pier, and how compare_airport_hotel behaves. It does not elaborate on limit or party_size beyond the schema, keeping it from a 5.

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 resource: recommend Seattle hotels with whole-trip costs including room rate and ride costs. It clearly scopes the output to a stay scenario rather than a generic hotel search or ride quote, which distinguishes it from most siblings.

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 clear usage context by explaining that near can be a cruise pier or hotel area and that pier searches also price a SeaTac airport hotel for comparison. It does not explicitly name alternative tools or state when not to use this one, so it falls short of the top score.

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?