Over The Planet

Find unique travel experiences

Find tours, activities, and hotels for your trip. Browse experiences with images, ratings, starting prices, options, and direct links.

What you can ask

Discover things to do in Tokyo, with photos and starting prices
Example path

MCP connector

Server URL: https://api.overtheplanet.com/mcp
Login: None
Protocol: MCP 2025-11-25
Instructions: Use these read-only Over The Planet tools for experiences and accommodation. If an experience request has no destination or the conversation does not clearly establish one, ask which city or area to search before calling . Never guess from locale, currency, or time zone. For 'near me', search only when a usable location is explicitly available; otherwise ask. Data tools return reusable results only and do not render a widget. For broad destination browsing, omit queryText/activityName unless the user names a particular activity; for a named activity, preserve the user's original wording in queryText and optionally include a clean activityName. The server resolves names and returns canonical publicIds, images and URLs, so never ask the user to supply an ID. If matching is ambiguous, ask the user to choose before follow-up. When rendering cards, copy every available HTTPS images[].url candidate from the preceding result into imageUrls in its original order; do not select just one image. Use an empty imageUrls array only if the preceding result returned no usable image URLs. For product links, include productType in linkContext. Do not invent an arrival/check-in date or copy implicit occupancy defaults. For activities, use the selected activity date for arriveAt and always set departAt to that same date, even when availability was checked over a range. For hotels, use the requested check-in and explicit check-out; when check-out is omitted, default departAt to two nights after arriveAt. Copy user-specified occupancy exactly. Copy destination.url to destinationUrl when available; never substitute the homepage. For a broad experience search with dates, call once with all publicIds returned by the search page (up to 10); it returns availability information previously recorded by Over The Planet and does not check with providers in real time. Explain this to users in plain language: prices and availability may have changed, so they should check current details on Over The Planet before booking. Do not expose implementation or storage terms. A missing availability result does not mean an activity is sold out. Do not fan out calls. Use only when the user asks for a live check of one specific activity. Use for lodging with dates and occupancy, and or for catalogue follow-up. Use the returned cancellationPolicies and freeCancellation summaries as the source of truth. isRefundable alone does not mean free cancellation. On a card, copy its product's freeCancellation object only when the status is all_options or some_options; never upgrade some_options to all_options or infer policy from price/refund flags. Populate product badges independently for every selected card when prior Over The Planet results provide extra product-specific facts, such as a location or route, inclusion, pass or option name, or availability detail. Prefer the two most useful concise facts, but the renderer defensively accepts a bounded longer list, shortens long badge text, and keeps only two for display. Never reuse one product's badges for another, and never invent facts. Keep rating, review count, duration, and language in their existing dedicated fields rather than duplicating them as badges; omit badges when no extra source-backed fact exists. Treat as a final, one-time presentation action: invoke it at most once, sequentially, only after all catalogue and requested availability calls finish and the shortlist is final. Never invoke it in parallel with data tools, for provisional results, or a second time to update the same answer. For two or more usable activity or hotel listings, pass 2–8 final selections. For one listing, render only when the user asks for a card or a product-specific details/availability answer benefits from one. Never render empty results or unresolved ambiguous candidates; if there is no usable final payload or rendering fails, answer in text without retrying the renderer. Use exact facts and URLs from preceding tool results, then keep final prose brief without repeating card details. Prices and availability are point-in-time; no tool books or charges.

Tools

Reads data7

Skills

None in the store listings or on the server

MCP connector

Server URL

https://api.overtheplanet.com/mcp

None

Protocol

MCP 2025-11-25

Instructions

Use these read-only Over The Planet tools for experiences and accommodation. If an experience request has no destination or the conversation does not clearly establish one, ask which city or area to search before calling . Never guess from locale, currency, or time zone. For 'near me', search only when a usable location is explicitly available; otherwise ask. Data tools return reusable results only and do not render a widget. For broad destination browsing, omit queryText/activityName unless the user names a particular activity; for a named activity, preserve the user's original wording in queryText and optionally include a clean activityName. The server resolves names and returns canonical publicIds, images and URLs, so never ask the user to supply an ID. If matching is ambiguous, ask the user to choose before follow-up. When rendering cards, copy every available HTTPS images[].url candidate from the preceding result into imageUrls in its original order; do not select just one image. Use an empty imageUrls array only if the preceding result returned no usable image URLs. For product links, include productType in linkContext. Do not invent an arrival/check-in date or copy implicit occupancy defaults. For activities, use the selected activity date for arriveAt and always set departAt to that same date, even when availability was checked over a range. For hotels, use the requested check-in and explicit check-out; when check-out is omitted, default departAt to two nights after arriveAt. Copy user-specified occupancy exactly. Copy destination.url to destinationUrl when available; never substitute the homepage. For a broad experience search with dates, call once with all publicIds returned by the search page (up to 10); it returns availability information previously recorded by Over The Planet and does not check with providers in real time. Explain this to users in plain language: prices and availability may have changed, so they should check current details on Over The Planet before booking. Do not expose implementation or storage terms. A missing availability result does not mean an activity is sold out. Do not fan out calls. Use only when the user asks for a live check of one specific activity. Use for lodging with dates and occupancy, and or for catalogue follow-up. Use the returned cancellationPolicies and freeCancellation summaries as the source of truth. isRefundable alone does not mean free cancellation. On a card, copy its product's freeCancellation object only when the status is all_options or some_options; never upgrade some_options to all_options or infer policy from price/refund flags. Populate product badges independently for every selected card when prior Over The Planet results provide extra product-specific facts, such as a location or route, inclusion, pass or option name, or availability detail. Prefer the two most useful concise facts, but the renderer defensively accepts a bounded longer list, shortens long badge text, and keeps only two for display. Never reuse one product's badges for another, and never invent facts. Keep rating, review count, duration, and language in their existing dedicated fields rather than duplicating them as badges; omit badges when no extra source-backed fact exists. Treat as a final, one-time presentation action: invoke it at most once, sequentially, only after all catalogue and requested availability calls finish and the shortlist is final. Never invoke it in parallel with data tools, for provisional results, or a second time to update the same answer. For two or more usable activity or hotel listings, pass 2–8 final selections. For one listing, render only when the user asks for a card or a product-specific details/availability answer benefits from one. Never render empty results or unresolved ambiguous candidates; if there is no usable final payload or rendering fails, answer in text without retrying the renderer. Use exact facts and URLs from preceding tool results, then keep final prose brief without repeating card details. Prices and availability are point-in-time; no tool books or charges.