Strong foundation with 18 well-named tools, comprehensive descriptions (avg 180+ chars), and explicit JSON Schema with type definitions and patterns. All tools are read-only with proper annotations (readOnlyHint, idempotentHint). Key strengths: detailed parameter constraints (date patterns, currency codes, enums for status), clear capability requirements, and thoughtful PII redaction (gift codes masked, webhook headers sanitized, contact fields dropped). Weaknesses: output schemas are not formally documented in tool definitions (responses are JSON.stringify'd without declared structure), error handling lacks recovery guidance (no 'try this next' messages), and some complex parameters (units array, nested product objects) could benefit from example structures in descriptions.
Check availability for specific time slots. Returns individual slots with availabilityId, exact start/end times, vacancies, pricing, and meeting point. Requires productId and optionId plus at least one selector: localDateStart+localDateEnd (date range, max 31 days), localDate (single date), availabilityId (single slot), or availabilityIds (multiple slots).
Check availability for specific time slots across multiple products. Returns individual slots per product/option with availabilityId, exact start/end times, vacancies, pricing, and meeting point. Use this to compare slot availability across products in a single request. Requires at least one selector: localDateStart+localDateEnd (date range, max 7 days), localDate (single date), availabilityIds (multiple slots).
Check daily availability calendar for a product over a date range. Returns one entry per day with available/sold-out status, vacancies, start times, and pricing summary. Use this for an overview of which days have availability. Dates must be YYYY-MM-DD. Max 31 days per request — split larger windows into multiple calls. Optionally pass units to check capacity for a specific group size.
Check daily availability calendar across multiple products over a date range. Returns entries per day per product/option. Use this to compare availability across products in a single request. Dates must be YYYY-MM-DD. Max 7 days per request — split larger windows into multiple calls.
Output schemas not formally documented. Tools return JSON.stringify'd responses without declared response structure. LLMs cannot plan downstream operations or validate field presence.
Error handling lacks recovery guidance. Tools call handleToolError() but do not return actionable next steps (e.g., 'Try list_products() first to find valid product IDs'). Raw API errors are not translated to LLM-friendly messages.
Complex nested parameters (units array with id/quantity objects, products array with productId/optionId) lack example structures in descriptions. LLMs may struggle to construct valid payloads.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Retrieve a specific booking by its UUID. Returns a curated allowlist of booking fields (status, product, option, unit items, pricing, meeting point, timestamps). Contact details, notes, ticket URLs, and any fields not explicitly whitelisted are dropped — see src/sanitize.ts for the full list.
Return the effective ventrata-mcp debug log file path.
Retrieve order details by order ID. Returns a curated allowlist of order fields including nested sanitized bookings, pricing, and status. Contact details and any fields not explicitly whitelisted are dropped — see src/sanitize.ts for the full list.
Get detailed information about a specific Ventrata product (tour) by its ID. Returns the full product including description, highlights, inclusions/exclusions, meeting point, pricing, images, and all options with units.
Get a single supplier's full profile by ID. Returns id, name, endpoint, country, and destinations array — `contact` (email/phone) is dropped via `sanitizeSupplier`. Same docs caveat as `list_suppliers`: not on docs.ventrata.com.
List bookings with filters. At least one primary filter is required: localDate (YYYY-MM-DD) for a single day, localDateStart + localDateEnd for a range, resellerReference/supplierReference, or utcCreatedAtStart/utcCreatedAtEnd for creation time range. Optional secondary filters: productId, optionId, status/statuses, page, perPage for pagination. Note: contact filter fields (email, phone, last name) contain PII that will appear in AI conversation context when used as search inputs.
List all OCTO capabilities supported by the supplier. Capabilities include: octo/pricing, octo/content, octo/questions, octo/cardPayments, octo/offers, octo/cart.
List gift cards. Requires at least one of `supplierReference` or `resellerReference`. If both are passed, the combined behavior (AND vs OR) is not documented by Ventrata — prefer passing only one. Response is passed through `sanitizeGift` allowlist: keeps id/uuid/status/currency/amount/balance/references/timestamps; drops customer/recipient contact PII; **masks `code` to `***<last4>`** (the full code is a redemption credential — masking keeps it discriminable for reconciliation without being redeemable if the transcript leaks). Needs `octo/gifts` in VENTRATA_CAPABILITIES (included in the default; only an issue if you override that env to a narrower set). Docs: https://docs.ventrata.com/capabilities/gift-vouchers
List ID mappings configured on this connection (maps internal IDs to OCTO IDs across products/options/units). Needs `octo/mappings` in VENTRATA_CAPABILITIES (included in the default; only an issue if you override that env to a narrower set). Docs: https://docs.ventrata.com/capabilities/mappings
List orders via the OCTO list endpoint. Requires at least one of: `supplierReference`, OR both `utcCreatedAtStart` + `utcCreatedAtEnd`, OR both `utcUpdatedAtStart` + `utcUpdatedAtEnd`. Date values are ISO-8601 (e.g. 2026-04-01T00:00:00Z). Each order in the response is passed through `sanitizeOrder` (same allowlist as `get_order`): keeps id/status/pricing/timestamps/product refs and nested sanitized bookings; drops contact PII. **Scale warning:** on high-volume suppliers this endpoint can exceed the 60 s client timeout even with a 1-day window — prefer a targeted `supplierReference` lookup when possible. Docs: https://docs.ventrata.com/capabilities/cart
List all available tour products from Ventrata. Returns a summary of each product: id, name, timezone, country, currency, and options with start times and unit types. Use this to discover products before checking availability.
List all suppliers this API key has access to. Returns supplier profiles: id, name, endpoint, country, and embedded destinations — the `contact` field (email/phone) and any other PII fields are dropped via the `sanitizeSupplier` allowlist before the response reaches the LLM. Uses default OCTO capabilities; no extra env setup required. **Note:** this endpoint is not currently documented on docs.ventrata.com — shape was verified by live probe against production (2026-04-23).
List webhook subscriptions the key's account has registered. Returns id, event, url, retryOnError, useContactLanguage, and a `headers` map — but the headers are passed through `sanitizeWebhookHeaders` first: Authorization / Cookie / X-API-Key / any key matching `/bearer|token|secret/i` is dropped, since webhook configs commonly include third-party bearer tokens for the subscriber's endpoint and those would otherwise leak into the LLM context. Only Content-Type / Accept / Accept-Language / User-Agent headers are preserved. Needs `octo/webhooks` in VENTRATA_CAPABILITIES (included in the default; only an issue if you override that env to a narrower set). Docs: https://docs.ventrata.com/capabilities/webhooks
Get the authenticated supplier/connection context. Returns supplier ID, name, and connection details. Useful for verifying API key validity.
Pagination not explicitly documented for list_* tools. list_bookings and list_orders accept page/perPage but descriptions do not state max results per page or total count behavior.
STDIO transport only. Server is not remotely accessible and cannot be used by hosted MCP clients. Limits deployment to local/containerized environments.