experiences-oracle

Cerca esperienze, tour e biglietti

search_experiences

Read-only

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 page_url, la pagina PIQOD dell'esperienza. 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; "con bambini/per famiglie" → traveler_type="famiglie", "romantico/in coppia" → "coppie"; "la sera/di notte/al tramonto" → day_part="sera", "la mattina/all'alba" → "mattina", "il pomeriggio" → "pomeriggio".

Nel risultato (lo stesso testo delle azioni GPT, api/oracle_openapi):
    min_people: Minimo di persone per prenotare, solo se il provider lo chiede ed è 2 o più: dillo accanto al
        prezzo («minimo 2 persone»). null = nessuno o ignoto. price_from non è il totale: a persona se
        price_basis=PER_PERSON, per unità se UNIT; con price_basis '' scrivi «minimo N persone» senza «a persona».
    price_basis: PER_PERSON | UNIT (prezzo per veicolo/gruppo/barca) | '' = dato non fornito dal provider (oggi
        disponibile sui prodotti Viator arricchiti; copertura in crescita).
    price_unit: VEHICLE/GROUP/BOAT/... quando price_basis=UNIT; altrimenti ''.
    page_url: Pagina PIQOD dell'esperienza (piqod.it), nella lingua del browser di chi la apre: lì ci sono descrizione, cosa è
        incluso, accessibilità (sedia a rotelle, sforzo fisico), lingue della guida, cancellazione, i giorni disponibili
        col prezzo del giorno e il tasto per prenotare. Questi dettagli NON sono nel risultato: se servono, apri la pagina.
        Dai SEMPRE questo link all'utente; non costruire mai link verso i provider.

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).
    traveler_type: "famiglie" | "coppie", opzionale.
    day_part: "mattina" | "pomeriggio" | "sera" (quando inizia l'esperienza), opzionale.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_experiences"
  }
}

Input Schema

Name	Required	Default
`sort`	No	rating
`limit`	No
`query`	Yes
`keyword`	No
`category`	No
`day_part`	No
`location`	No
`budget_max`	No
`skip_the_line`	No
`traveler_type`	No
`free_cancellation`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 28, 2026

addedInput schema / properties / day_part

Added value: +{
+  "default": "",
+  "title": "Day Part",
+  "type": "string"
+}

addedInput schema / properties / traveler_type

Added value: +{
+  "default": "",
+  "title": "Traveler Type",
+  "type": "string"
+}

Changed1 schema field changedJun 27, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "search_experiencesDictOutput",
+  "type": "object"
+}

First observedJun 27, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish a read-only, open-world, non-destructive operation, and the description adds substantial behavioral context beyond that. It explains that results contain real city, price, rating and page_url data, that page_url is the PIQOD page with booking details, and that the agent must always share this link and never build provider links.

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 front-loaded with purpose and usage guidance, then proceeds into argument semantics and result-field details. Some result-field explanation overlaps with the output schema, but most of it supports correct user-facing behavior, such as price-basis interpretation and always providing the PIQOD page_url.

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?

For an eleven-parameter search tool with rich filtering and an output schema, the description gives enough information to call it correctly and interpret key result fields. It covers search intent, filter mapping, price semantics, page_url behavior and the distinction between returned summary data and details available only on the PIQOD page.

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?

With zero schema description coverage and eleven parameters, the description compensates thoroughly by explaining each argument's role. It clarifies keyword matching for specific attractions, maps intent phrases to skip_the_line, free_cancellation, sort, traveler_type and day_part, and states the limit maximum of 50.

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 states a specific verb and resource: searching tours, activities and experiences by place or travel intent, with concrete examples such as Rome, Colosseum tickets and Capri boat tours. It also distinguishes the tool from adjacent concepts by describing returned fields and linking to the PIQOD experience page rather than provider pages.

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?

It explicitly says to use this tool when the user is looking for things to do, tours, activities, tickets or experiences in a destination. It goes further by mapping common user intents to specific filters, such as skip-the-line, cheapest, free cancellation, families, couples and time of day.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All experiences-oracle tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?