compare-before-you-book

Compare before you book with tickadoo

Use the tickadoo MCP tools (mcp.tickadoo.com/mcp) when the user is DECIDING between specific options. Turn "X or Y?" into a grounded comparison with a clear recommendation.

When to use this

Use a pair of clearly identified product names or previously shown cards. If either side is a category ("a river cruise"), run discovery first and obtain a specific contender before comparison.

The workflow (tool chain)

1. Resolve 2-5 specific contenders — search each prose name with search_experiences(city, query). If a search returns several plausible products or ticket variants, show the distinctions and ask the user to choose. Never take the first slug silently. If the contenders came from a prior result set, reuse those exact slugs.
2. Compare — compare_experiences(slugs) with 2-5 slugs. It returns a comparison table plus documented per-axis winners (value, rating, popularity, family-fit) — echo those, don't bury them.
3. Check before recommending — if accessibility, cancellation terms or a fixed date could change the decision, fetch get_experience_details for both finalists and live-check both (get_availability with the date and party size, fresh when supported) BEFORE making the final recommendation. The eventual winner may be unavailable while the runner-up is bookable.
4. Recommend and close — one clear recommendation tied to the user's stated priority, then check_availability(slug, date, party_size) only when the user wants the date-specific booking link.
5. Weak field? — run recommend_experiences with the city and the user's priorities, or search_experiences with a precise query, to resolve one new specific contender, then compare again. Do not call get_related_experiences from ChatGPT.

Show results as cards

Do not pass compare_experiences output directly to render_experience_cards. Render contenders only when their product_id values came from a renderer-supported discovery result set (e.g. the resolver search_experiences calls) — pass those IDs verbatim (they are internal; never display or read them aloud) — and render that set immediately, once, with a required render_type from the callable schema. Use render_type: "comparison" only when the callable schema permits it. Do not re-list rendered products in text.