A
licenseA
qualityF
maintenanceReal-time last-minute tour and activity booking across 18 suppliers in 15 countries via the OCTO open standard. Search available slots, create Stripe checkout sessions, and check booking status.
4
1
MIT
experiences-oracle
by it.piqod
Server Details
Search & compare prices for tours, activities and tickets across multiple providers.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
TDQS
A4.4/5.0
Scored across 3 tools
Disambiguation4/5
The tools are mostly distinct: search_experiences handles general queries with filters, get_destination_guide provides curated top experiences for a destination, and compare_experience focuses solely on price comparison for a specific experience. However, search_experiences and get_destination_guide can overlap in returning experience options for a place, though their intended use cases are clarified in the descriptions.
Naming Consistency5/5
All tool names follow the same verb_noun pattern in lowercase snake_case: compare_experience, get_destination_guide, search_experiences. This is consistent and predictable, making it easy to infer the function of each tool from its name.
Tool Count4/5
With 3 tools, the server is slightly on the smaller side but well-scoped for its purpose of travel experience search, guide, and price comparison. The tools cover the core functions without unnecessary bloat, and the count feels appropriate for a niche domain.
Completeness4/5
The tool set covers the main workflows: searching experiences, getting a destination guide, and comparing prices for a specific experience. A minor gap is the lack of a dedicated tool for viewing detailed experience information or reviews, but the existing tools integrate well (search → compare) and cover most user needs.
Available Tools
3 toolscompare_experienceConfronta il prezzo tra i providerARead-onlyInspect
Confronta il prezzo della STESSA esperienza tra i provider (Viator, Tiqets, Headout) e indica dove costa meno, con un verdetto e il link di prenotazione. USA QUESTO TOOL quando l'utente vuole il MIGLIOR PREZZO per un tour/attività specifico (passa l'experience_id ottenuto da search_experiences).
Args:
experience_id: id dell'esperienza (es. "viator_12345").
query: (opzionale) la richiesta originale dell'utente — migliora
l'attribuzione del click; se assente si usa il titolo.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| experience_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds behavioral context about what the tool returns (where it costs less, verdict, booking link) and how the optional query influences click attribution. It does not contradict the annotations, though it could add more about failure modes or data freshness.
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?
The description is compact and front-loaded with the main purpose, followed by usage guidance and a clearly formatted Args section. Every sentence contributes necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description covers the core flow, prerequisite (experience_id from search_experiences), and expected output. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining experience_id with an example ('viator_12345') and query's optional role and effect on attribution, adding genuine semantic value beyond the bare schema.
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?
The description uses a specific verb ('Confronta il prezzo') and clearly identifies the resource ('la STESSA esperienza tra i provider') and the outcome (verdict and booking link). It also distinguishes from siblings by requiring an experience_id from search_experiences and focusing on best-price comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'USA QUESTO TOOL quando l'utente vuole il MIGLIOR PREZZO per un tour/attività specifico'. It also names the sibling tool search_experiences as the source for the required experience_id, providing clear context and an implied alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_destination_guideGuida: le migliori esperienze di una destinazioneARead-onlyInspect
Le migliori esperienze e cose da fare in una destinazione (città o paese), ordinate per qualità, con link di prenotazione. USA QUESTO TOOL quando l'utente pianifica un viaggio o chiede le TOP attività/esperienze di un posto.
Args:
place: città o paese (es. "Roma", "Giappone").
limit: numero risultati (max 30).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| place | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the description carries less burden. It adds context about ordering by quality and including booking links, which is useful but not extensive. There is no contradiction with annotations.
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?
The description is concise with no wasted words. It begins with a clear statement of purpose, followed by usage guidance, then a parameter list. The structure is logical and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set (2 parameters, 1 required), 0% schema coverage, and presence of output schema, the description covers input explanations and output content (ordered experiences with booking links). It is complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does so by explaining 'place' as a city or country with examples, and 'limit' as number of results with a maximum of 30. This adds complete meaning beyond the schema's type and default.
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?
The description clearly states that the tool retrieves the best experiences and things to do in a destination, ordered by quality, with booking links. It distinguishes itself from sibling tools by focusing on a guided list of top activities, which is explicitly compared to 'compare_experience' and 'search_experiences'.
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?
The description explicitly says when to use the tool: when the user is planning a trip or asking for top activities/experiences. It does not explicitly say when not to use it, but the sibling tools imply alternatives, and the guidance provided is clear and contextual.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_experiencesCerca esperienze, tour e bigliettiARead-onlyInspect
Cerca tour, attività ed esperienze da prenotare in un luogo o per un intento
di viaggio (es. "cosa fare a Roma", "biglietti per il Colosseo", "tour in barca a
Capri"). Restituisce risultati reali con città, prezzo, rating e un link di
prenotazione (redirect PIQOD affiliato). USA QUESTO TOOL quando l'utente cerca
cose da fare, tour, attività, biglietti o esperienze in una destinazione.
IMPORTANTE per la coerenza: se l'utente nomina un'ATTRAZIONE/attività precisa
(es. "tour del Colosseo"), passa quel nome in keyword (es. "Colosseo") → i
risultati saranno SUL Colosseo, non genericamente vicini. Mappa anche gli INTENTI
sui filtri: "salta fila/skip the line" → skip_the_line=True; "più economico/cheapest"
→ sort="price"; "cancellazione gratuita" → free_cancellation=True.
Args:
query: intento o luogo dell'utente.
location: luogo esplicito (override di query), opzionale.
category: categoria/filtro tematico, opzionale.
budget_max: prezzo massimo, opzionale.
keyword: attrazione/attività specifica da matchare nei titoli (es. "Colosseo").
skip_the_line: True se l'utente vuole biglietti/tour "salta fila".
free_cancellation: True se vuole cancellazione gratuita.
sort: "price" per i più economici prima (default "rating").
limit: numero risultati (max 50).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | rating | |
| limit | No | ||
| query | Yes | ||
| keyword | No | ||
| category | No | ||
| location | No | ||
| budget_max | No | ||
| skip_the_line | No | ||
| free_cancellation | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and destructiveHint, so the burden is lower. The description adds useful behavioral context: it returns real results, redirects to a PIQOD affiliate link, and explains parameter behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured with a clear flow: what it does, when to use, important notes, parameter mapping. It could be slightly more concise, but every sentence adds value. The bilingual Italian-English may cause minor readability issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, 1 required) and the presence of an output schema, the description covers all necessary aspects: purpose, usage with examples, parameter semantics, and behavioral traits (affiliate redirect). It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so thoroughly, explaining each parameter's meaning and how to map user intents (e.g., keyword for specific attractions, skip_the_line for skip-the-line requests). This far exceeds the baseline needed for 9 parameters.
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?
The description clearly states the tool searches for tours, activities, and experiences to book in a location or travel intent. It uses specific verbs ('Cerca') and resources ('tour, attività ed esperienze'), and distinguishes itself from siblings by mentioning it returns real results with city, price, rating, and an affiliate link.
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?
The description explicitly says 'USA QUESTO TOOL quando l'utente cerca cose da fare...' and provides detailed guidance on mapping user intents to parameters (e.g., 'skip-the-line' -> skip_the_line=True). However, it does not explicitly state when not to use it or offer alternatives to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- Changed
compare_experience1 field changed- added
Input schema / properties / queryAdded value: +{ + "default": "", + "title": "Query", + "type": "string" +}
3 tool updates
- Changed
compare_experience1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "title": "compare_experienceDictOutput", + "type": "object" +}
- Changed
get_destination_guide1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "title": "get_destination_guideDictOutput", + "type": "object" +}
- Changed
search_experiences1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "title": "search_experiencesDictOutput", + "type": "object" +}
3 tool updates
- First observed
compare_experience - First observed
get_destination_guide - First observed
search_experiences
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Search and book theatre, attractions, tours across 681 cities. 13,090+ products.
Search tours, attraction tickets, and holiday packages across 24 countries.
Search and compare outdoor experiences. Public keyless API; booking and payment happen on Viator.
Search and book last-minute tours and activities in 28 cities from 21 suppliers.
Related MCP Servers
- AlicenseAqualityCmaintenanceDiscover and book theatre, shows, events, tours and experiences across 700+ cities worldwide on tickadoo® with real-time pricing and booking links.4181MIT
- AlicenseNot gradedqualityBmaintenanceBook hotels worldwide — search, price, prebook & book across 249 countries. 65 tools for hotel search, flights, loyalty, analytics. Zero API keys needed. at best prices for hotels 3 M+ property71MIT
- FlicenseNot gradedqualityFmaintenanceSearch flights, compare prices, check visas, look up airports, get travel advisories through a single endpoint.-
