Loading ToolBench
MCP server for conversational trip planning with MyNextAdventure API. Provides tools to create, manage, and modify trips, variants, destinations, accommodation/transport options, and events.
The MyNextAdventure MCP server demonstrates strong tool design fundamentals with 22 well-curated tools covering a coherent trip-planning domain. Naming is consistently action-verb-based (list_*, create_*, update_*, add_*, select_*, delete_*). Tool descriptions are substantive (average ~150 chars) and include context about when to call tools and their prerequisites. Schemas are complete with parameter types and descriptions. However, output schemas are not documented in the manifest (no return type descriptions visible), and error handling guidance is minimal. Tool composition is excellent, tools chain logically (list_trips → get_trip → create_variant → add_destination, etc.), and all necessary IDs for downstream calls are returned. Parameter descriptions follow good practices (e.g., includeAllOptions, includeExample, confirm flags). One weakness: the codebase shown does not expose the full input/output schemas in the source snippets provided, though the manifest references operationIds suggesting they are derived from an OpenAPI spec (spec/openapi-v1.json). This limits verification of output structure quality.
Propose somewhere to stay at a destination — hotel, hostel, apartment, house or camping. Add several options to the same destination so the user can compare them, then use select_destination_option once they pick one. Always include the total cost and currency, otherwise the trip budget will be wrong.
Add a place the traveller will stay at within a variant, in itinerary order (e.g. "Lisbon, Portugal"). Destinations are what accommodation, transport and getting-around options attach to, so add these before adding options. Set isReturnToHome for the final leg home.
Add an activity or event to the variant — something to do or see during the trip. Events attach to the variant as a whole, not to a specific destination, but include dates. Museums, hiking, restaurant reservations, concerts, etc. Include cost and currency if there is a ticket price.
Propose local transport within a destination — car rental, public transit pass, or walking. Add several so the user compares them, then select one. Include total cost and currency.
Propose a way to get from one destination to the next — flight, train, bus, car or ferry. Add several options so the user can compare prices and travel times, then select once they decide. Always include the total cost and currency.
Output schemas not documented. While tool descriptions and input schemas are complete, no explicit documentation of return types, fields, or structure is visible in the manifest or code samples. This forces LLMs to infer output structure from tool names and descriptions alone, increasing hallucination risk when chaining tools.
Limited error handling guidance. No evidence of error classification (retryable vs. user-fixable vs. fatal), recovery hints, or actionable error messages in the tool definitions. This leaves LLMs unable to decide whether to retry, ask the user, or abort.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
Create a new, empty trip — the container everything else hangs off. This is step 1 of planning: create the trip, then create_variant for the dates, then add_destination, then the accommodation / transport / event options. Ask the user for a name if they have not given one.
Create (or refresh) a public read-only link to the trip so the user can send the plan to people without an account. Returns the shareable URL. Use when the user asks to share, send or publish a trip.
Add an alternative version of the trip — "Beach option" vs "Mountain option", or the same route on different dates. A trip needs at least one variant before it can hold destinations or options, so create one right after create_trip. Dates live on the variant: either exact start/end dates or a flexible window with min/max nights.
Permanently delete a destination, option, or event from the variant. This cannot be undone — prefer deselecting or toggling where possible. Requires explicit confirmation via a confirm flag (set to true) to prevent accidental deletions.
Copy a variant, with all of its destinations and options, into a new variant on the same trip. Use when the user wants to explore a tweak ("same trip but a week later", "same route, cheaper hotels") without losing the original.
Fetch one trip in full: its variants, destinations, accommodation / transport / getting-around options and events. Call this before changing anything — every other tool needs the variant ids, destination keys and option keys this returns.
List the traveller's goals or interests that can guide trip planning — adventure, relaxation, culture, food, nature, budget, luxury, family-friendly, etc. Use this to understand what matters to the user and to guide suggestions.
List the trips the user owns or collaborates on. Start here whenever the user refers to a trip by name ("my Japan trip") so you can resolve it to a trip id. Statuses: 'planning' is actively being worked on, 'ready' is planned but not taken yet, 'finished' is in the past, 'cancelled' was dropped. Call with no filters to see everything.
Rearrange the itinerary order of a variant's destinations. Use after adding stops out of order, instead of deleting and re-adding them.
Choose which accommodation / transport / getting-around option the plan will use. Can be called with no action to see the current selection, or with discriminator set to an action: select_option to pick one, deselect_option to unselect, or compare_options to show several side by side.
Mark one variant as the trip's chosen plan. Use when the user decides between alternatives; the choice is reversible, so selecting a different variant later is fine.
Change a destination's place name, its arrival/departure dates, or its notes. Use this to pin down when the traveller is in each place once the dates firm up, rather than deleting and re-adding the stop.
Change an event's name, description, dates, cost, or notes.
Update the traveller's goals or interests to guide trip planning. Pass the full list you want — it replaces the existing goals entirely (not additive).
Change top-level trip fields: rename it, set a cover photo, or move it through its lifecycle (planning -> ready once the plan is settled, finished or cancelled afterwards). Does not touch variants, destinations or options.
Rename a variant, change its dates (exact dates or a flexible window), or edit its notes.
Check which MyNextAdventure account the current API key belongs to. Use this when you are unsure whether the connection is authenticated, or to confirm whose trips you are about to change before making edits.
Destructive tool (delete_trip_item) includes confirm flag but other state-changing operations (update_*, add_*) lack confirmation or dry-run safeguards. Agents can inadvertently modify plans without explicit user confirmation.
Missing property descriptions in complex object parameters. Tools like add_accommodation_option, add_transport_option, add_getting_around_option, add_event accept 'data' objects with 'required:true' but no inline description of required sub-properties (name, cost, description, etc.). The manifest shows 'properties' in schema but their individual descriptions are not visible in the source snippets.