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.

Input Schema

TableJSON 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

TableJSON 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 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.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), but the description adds real behavioral context: slots that cannot fit the group are omitted, party_size wins over travelers, and the status field enumerates ok/no_schedule/no_fit/calendar_gone. It stops short of error handling or rate-limit behavior.

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?

Three sentences with no filler; the core capability is front-loaded, followed by the input-precedence rule and the downstream tool. Every sentence carries information an agent needs.

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, the return shape need not be explained, and the description still adds status-value semantics. Complete enough to call correctly; only minor gaps around error or timezone behavior remain.

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 60%, so the baseline is 3. The description restates precedence rules and the 31-day cap that the schema largely already documents, adding little beyond what the schema and its nested descriptions provide.

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 ('Check live start times and remaining seats for a TripWays tour') and bounds the scope ('one date or a range of up to 31 days'). An agent can distinguish this from search_tours or get_tour_details without opening a 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?

Explicitly routes the agent to get_price_quote with the same date, start time, and travelers for totals, which is a clear alternative-tool handoff. It also clarifies the party_size vs travelers precedence. It does not state when-not to use this tool, so it falls short of the full when/when-not/alternatives bar.

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

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?