TripWays

Check availability

check_availability

Read-onlyIdempotent

Check live start times and remaining seats for a TripWays tour on one date or a range of up to 31 days. Pass party_size (seats needed) or a travelers object; slots that cannot fit the group are left out, and party_size wins if both are given. The status field is ok, no_schedule, no_fit, or calendar_gone. Use get_price_quote with the same date, start time, and travelers for the total; its rate_options name and price the options in rate_ids.

Input Schema

Name	Required	Description
`date`	Yes
`bokun_id`	Yes
`date_end`	No	Inclusive end; default = date. Max 31 days.
`travelers`	No	Simple ages; mapped to occupied seats (infants excluded unless the tour has an infant category). Used only when party_size is omitted.
`party_size`	No	Occupied seats to keep (not ticket count). Slots with availabilityCount < party_size are omitted unless unlimited. Wins over travelers when both are set.

Output Schema

Name	Required	Description
`ok`	Yes
`note`	No
`error`	No	Present when ok is false. code: tour_not_found, destination_not_found, destination_ambiguous, or unpriced. message is written for the traveler.
`slots`	No	Open start times that fit the party.
`reason`	No
`status`	No	ok, no_schedule, no_fit, or calendar_gone.
`bokun_id`	No
`checkout_url`	No
`bookable_natively`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026
- addedOutput schema / properties / slots / items / properties / rate_ids / description
```
Added value: +"Options (rate ids) offered at this start time."
```

Changed1 schema field changedOct 2, 2026

addedOutput schema / properties / error

Added value: +{
+  "description": "Present when ok is false. code: tour_not_found, destination_not_found, destination_ambiguous, or unpriced. message is written for the traveler.",
+  "properties": {
+    "code": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 29, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations' read-only and idempotent hints, the description discloses the filtering behavior ('slots that cannot fit the group are left out'), the precedence rule between party_size and travelers, the 31-day range cap, and the status values ok, no_schedule, no_fit, and calendar_gone. These are substantive behavioral traits that help an agent interpret results correctly.

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 purpose and then moves efficiently through input selection, status values, and the get_price_quote handoff. It is dense but appropriately sized; the final sentence about rate_options and rate_ids is slightly compressed but still earns its place by linking to the pricing sibling.

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?

An output schema exists, so return values need not be fully explained, and the description still names the status values and the sibling to use for pricing. It leaves the meanings of no_schedule, no_fit, and calendar_gone implicit, but overall it gives enough context for an agent to call the tool correctly.

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 60%, and the description mostly restates what the schema already says about party_size, travelers, and their precedence. It adds little for the undocumented bokun_id and date parameters, and does not explain formats or edge cases beyond the schema's own patterns and constraints.

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 gives a specific verb and resource ('Check live start times and remaining seats') plus the exact scope: a TripWays tour, one date or a range up to 31 days. It also distinguishes this tool from get_price_quote by assigning pricing to that sibling, so an agent can tell them apart without reading the 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?

It clearly says to use get_price_quote with the same date, start time, and travelers for the total, which gives a concrete handoff condition. It also states party_size wins over travelers when both are supplied. It does not explicitly list when not to use this tool, so it stops short of a full when/when-not routing statement.

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

All TripWays 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?