tickadoo-mcp
Server Details
Search and book theatre, attractions, tours across 681 cities. 13,090+ products.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- tickadoo/tickadoo-mcp
- GitHub Stars
- 1
- Server Listing
- tickadoo
Available Tools
23 toolscheck_availabilityARead-onlyInspect
Use this when the user has picked a specific experience and asks about exactly one date: whether it is available that day, what it costs for a party, or a booking link for that date. For browsing a date range or listing upcoming times and live slot prices, use get_availability.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date to check in YYYY-MM-DD format. | |
| slug | Yes | Product slug or legacy booking path, e.g. "london-dungeon-tickets" or "/london/london-dungeon-tickets". | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. | |
| party_size | No | Number of guests or tickets to price. Default 2. |
Output Schema
| Name | Required | Description |
|---|---|---|
| date | No | |
| slug | No | |
| slots | No | |
| title | No | |
| detail | No | |
| message | No | |
| available | No | |
| error_type | No | |
| schema_version | No | |
| total_for_party | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds some behavioral context by indicating the tool returns availability, pricing for a party, and a booking link, but does not go deeper into response shape or edge cases. This is sufficient but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The critical usage condition is front-loaded, and the sibling routing appears immediately after, making it very easy for an agent to parse and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter tool with a high-quality schema and an output schema, the description covers the main invocation context, the exact date constraint, the supported question types, and the alternative tool. Nothing essential for selecting or invoking this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented structurally. The description maps to date and party_size conceptually but adds no new parameter semantics beyond the schema. A baseline of 3 is appropriate when the schema already carries the full definitional load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (check), a clear resource (availability for a specific experience), and a precise scope (exactly one date). It explicitly contrasts itself with get_availability, making its unique role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit conditions for use: user has picked a specific experience and asks about exactly one date. It also names the alternative (get_availability) and the conditions under which that alternative should be chosen, such as browsing a date range or listing upcoming times.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_experiencesARead-onlyIdempotentInspect
Use this when the user wants a side-by-side comparison of 2-5 specific products. Pass the slug for each. Returns a comparison table plus per-axis winners (value, rating, popularity, family-fit).
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | Product slugs from earlier search or recommend results. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| text | No | |
| detail | No | |
| winner | No | |
| message | No | |
| comparison | No | |
| error_type | No | |
| differences | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety is transparent. However, the description says it 'Returns a comparison table,' while the schema's format parameter states text format returns 'a short narrative paragraph' — so the claimed output shape is not accurate across all supported modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the use case, and no filler. It earns most of its space, but the 'comparison table' wording is slightly imprecise given the text/narrative format option, which costs a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering the safety profile, the description is mostly complete: it communicates cardinality, required input, and output highlights. The only material gap is the inconsistent return-format claim, which could mislead an agent choosing between json and text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents slugs, format, and language. The description only restates the slug requirement and adds no new parameter semantics beyond what the schema provides, so it stays at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation — side-by-side comparison — and bounds it to 2-5 specific products. It also previews the output (comparison table plus per-axis winners), which distinguishes it clearly from search, recommendation, and detail-lookup siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: 'Use this when the user wants a side-by-side comparison of 2-5 specific products.' It does not explicitly name alternative tools or state when not to use it, so it misses the full 5, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_nearby_experiencesARead-onlyIdempotentInspect
Use this when the client already holds exact latitude and longitude coordinates and wants experiences near that point. When only a place name, landmark, or neighbourhood is known, use search_local_experiences, which accepts coarse place hints and needs no coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| category | No | Optional category slug. | |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. | |
| latitude | Yes | Latitude coordinate. | |
| longitude | Yes | Longitude coordinate. | |
| radius_km | No | Search radius in kilometres. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| request_id | No | |
| experiences | No | |
| _normalization | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a useful precondition (exact coordinates are required) but does not disclose additional runtime behavior such as result ordering, pagination, or response shape beyond what the schema/output schema already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The primary use case is front-loaded, the alternative tool is named, and the differentiating condition is clear. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only geolocation search tool with a rich schema and output schema, the description gives the necessary invocation context and points to the right alternative. No additional context about return values is needed because the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, and most parameters already have descriptions for latitude, longitude, limit, format, category, language, and radius_km. The description only reinforces that 'exact latitude and longitude coordinates' are expected, but this is already visible in the schema. It does not meaningfully extend parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb plus resource: find experiences near a point using exact latitude/longitude. It also distinguishes itself from the sibling search_local_experiences, making its purpose immediately identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('when the client already holds exact latitude and longitude coordinates') and when not to use it: when only a place name, landmark, or neighbourhood is known, use search_local_experiences. This is explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_availabilityARead-onlyInspect
Use this when the user is ready to check live bookable dates, times, prices, or remaining spaces for one selected product. This is the live supplier-check tool; pass product_id from search or slug plus city_slug. Slot price.amount is in MINOR currency units (pence/cents): amount 13125 with currency_code GBP means GBP 131.25. Slot time is venue-local; when the venue timezone is known, timezone carries its IANA name and datetime/next_available carry the real UTC offset (e.g. 2026-07-18T19:30:00+02:00), so they are safe for time math.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Product slug. Use with city_slug when product_id is unavailable. | |
| as_of | No | Previous ISO timestamp from stale card data; returns delta only when data changed. | |
| fresh | No | When true, bypasses the 60-second cache and performs a live supplier check, subject to rate limits. | |
| date_to | No | End date in YYYY-MM-DD. Defaults to 14 days after date_from and is capped to a 365-day window. | |
| city_slug | No | City slug required when slug is used. | |
| date_from | No | Start date in YYYY-MM-DD. Defaults to today. | |
| party_size | No | Number of guests. Default 2. | |
| product_id | No | Stable product_id from a search or details response. Preferred when available. | |
| preferred_time | No | Optional broad time preference such as morning, afternoon, or evening. | |
| idempotency_key | No | Optional UUID. Reuse for identical responses within five minutes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| slug | No | |
| slots | No | |
| detail | No | |
| message | No | |
| timezone | No | |
| error_type | No | |
| product_id | No | |
| total_slots | No | |
| inventoryLevel | No | |
| next_available | No | |
| schema_version | No | |
| provenance_level | No | |
| book_now_confidence | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining that price.amount is in minor currency units and that slot times are venue-local with timezone offsets safe for time math. These are exactly the kind of pitfalls that prevent unit and timezone errors. It aligns with readOnlyHint=true and destructiveHint=false, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each doing work: purpose, product selection, currency-unit warning, and timezone warning. No filler, and the most important usage guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage, output schema, and annotations, the essentials are covered: when to use, what input to supply, and how to interpret money and time. The description is complete enough for an agent to call correctly; remaining details are left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 10 parameters have descriptions in the schema, so the baseline is 3. The description mostly restates the product_id/slug+city_slug selection rule already in the schema and adds little new parameter-level semantics. The price/time details relate to output interpretation rather than parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('check live bookable dates, times, prices, or remaining spaces') and a resource ('one selected product'), clearly distinguishing this from broader search/exploration tools. However, a sibling named check_availability exists and the description never explicitly differentiates the two, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger ('Use this when the user is ready to check live bookable...') and a routing rule ('pass product_id from search or slug plus city_slug'). It does not mention when not to use it or name alternatives such as check_availability, so it gets a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_city_guideARead-onlyIdempotentInspect
Use this when the user wants an orientation overview of a city for trip planning. Returns a ranked list of the city's most popular bookable experiences (search rows); derive the dominant categories and price levels from those rows rather than expecting a structured guide payload.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| request_id | No | |
| experiences | No | |
| _normalization | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as a safe, read-only, idempotent operation. The description adds valuable behavioral context beyond that: the response is actually a ranked list of search rows, and the agent must derive categories and price levels from those rows rather than expecting a structured guide. This prevents a major misinterpretation of the return payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the trigger use case, the second states the return shape and the key interpretive instruction. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, the schema fully documents its parameters, annotations cover safety, and an output schema exists. The description fills the one important gap by explaining how to interpret the returned rows. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters in full, so the schema carries the semantic weight. The description adds no additional parameter-level detail, which is acceptable given the 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an orientation overview of a city for trip planning: a ranked list of popular bookable experiences. It also clarifies that no structured guide payload should be expected. While it doesn't explicitly name sibling alternatives, the use case and output format are specific enough to set it apart from search and tip tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description opens with an explicit when-to-use condition: 'when the user wants an orientation overview of a city for trip planning.' It doesn't enumerate alternatives or exclusions, so it stops short of full routing guidance, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_date_nightARead-onlyIdempotentInspect
Use this when the user wants an evening for two. Returns a flat ranked list of evening-appropriate experiences (search rows), not a structured pre-dinner/dinner/show arc, and rows are not guaranteed couples-filtered. Compose the evening yourself (search_by_mood with mood 'romantic' can bias the pool).
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug. | |
| date | No | Optional ISO date (YYYY-MM-DD). | |
| budget | No | Budget band. 'low' = under 100 per person, 'medium' = 100-200, 'high' = 200+. In the listed currency. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| request_id | No | |
| experiences | No | |
| _normalization | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description goes beyond annotations by disclosing the output shape (flat ranked list, not a structured arc), the limitation that rows are not guaranteed couples-filtered, and that the agent must compose the evening itself. These are meaningful behavioral caveats not present in the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. The trigger condition is front-loaded, followed by the output caveat, then the alternative pointer. Every sentence contributes a distinct piece of decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema, annotations, and full parameter coverage, the description covers the remaining gaps: exact use case, output shape, key limitation, and a named alternative. An agent has everything needed to select and invoke this tool correctly alongside its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already described in detail (city slug, ISO date, budget band with explicit ranges, format enum, language code). The description adds no additional parameter-level meaning, so the baseline 3 applies. No compensation is needed because the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise trigger condition ('when the user wants an evening for two') and names the exact deliverable: 'a flat ranked list of evening-appropriate experiences (search rows)'. It also distinguishes itself from the structured pre-dinner/dinner/show arc, which is a different tool's behavior, and references search_by_mood as an alternative. This clearly separates it from the many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool and provides an alternative for a related need: 'search_by_mood with mood 'romantic' can bias the pool'. It also warns that rows are not guaranteed couples-filtered, giving an agent a reason to prefer another tool when strict filtering matters. This is actionable decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_experience_detailsARead-onlyIdempotentInspect
Use this when the user selects a specific experience from search results and needs richer product, location, supplier, and booking fields. Accepts either product_id or slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Product slug from a previous search result. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. | |
| product_id | No | Stable product_id from a previous search result. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| product | No | |
| products | No | |
| error_type | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context about richer fields but does not disclose edge behavior such as requiring at least one identifier or what happens if neither is provided. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with the purpose front-loaded and no redundant wording. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety and an output schema defining the return shape, the description only needs to convey when to call and what identifier to pass; it does both. It would be a 5 if it explicitly required one of product_id/slug, since the schema currently lists zero required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents all four parameters at 100% coverage, so the baseline is 3. The description adds the 'either product_id or slug' relationship and source context, but it does not add significant meaning beyond the schema and does not explicitly state a one-of requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the follow-up for a specific experience selected from search results and lists the richer field categories (product, location, supplier, booking). It distinguishes itself from search/recommendation siblings, though it lacks an explicit action verb like 'retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger condition ('user selects a specific experience from search results') and states that either product_id or slug can be used. It does not explicitly name alternatives or exclusion cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_family_dayARead-onlyIdempotentInspect
Use this when the user wants family-suitable options for a day in one city. Returns a flat ranked list of family-appropriate experiences (search rows), not a structured morning/lunch/afternoon/evening plan. Compose the day yourself and verify age suitability per pick via get_experience_details.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug. | |
| date | No | Optional ISO date (YYYY-MM-DD). | |
| budget | No | Optional max budget in the listed currency. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. | |
| kids_ages | No | Children's ages. Drives age-suitability filtering on each slot. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| request_id | No | |
| experiences | No | |
| _normalization | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the tool is read-only and idempotent. The description adds meaningful behavioral context: the output is a flat ranked list of search rows, not a structured itinerary, and the agent must compose the day and verify age suitability via get_experience_details. This goes beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The primary use case is front-loaded, followed by a precise output clarification and a concrete follow-up instruction. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema, full parameter schema coverage, and annotations that establish read-only safe behavior, the description provides the essential operational details: what the result looks like, what it is not, and how to handle age suitability. Nothing critical is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all six parameters including city, date, budget, format, language, and kids_ages. The description itself adds no parameter-specific meaning beyond the general family-day context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific use case ('family-suitable options for a day in one city'), a specific resource ('family-appropriate experiences'), and explicitly clarifies the return shape as a flat ranked list rather than a structured plan. This clearly distinguishes it from broader search or planning tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool ('when the user wants family-suitable options for a day in one city') and what not to expect ('not a structured morning/lunch/afternoon/evening plan'). It also directs the agent to use get_experience_details for age verification, though it does not explicitly name or exclude sibling tools like get_date_night.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_last_minuteARead-onlyInspect
Use this when the user wants something to do within the next few hours. Returns currently-on-sale experiences with seasonal products filtered out, ranked by popularity. Rows may include start_time, countdown_text, and seats_remaining hints when known, but none are guaranteed: confirm the selected experience with get_availability before stating it starts soon or is available today.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug. | |
| hours | No | How many hours ahead to look (1-12). Default 3. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. | |
| latitude | No | Optional latitude to bias toward nearby venues. | |
| longitude | No | Optional longitude to bias toward nearby venues. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| request_id | No | |
| experiences | No | |
| _normalization | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that returned time-related fields are not guaranteed and explicitly instructs the agent to confirm with get_availability before asserting availability. This is valuable behavioral context that prevents overclaiming.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficiently packed sentences with the trigger condition front-loaded and the caveat placed at the end. Every clause earns its place, and there is no redundant restating of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description covers the key behavioral essentials: use case, ranking, seasonal filtering, field uncertainty, and the mandatory confirmation step. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents all six parameters, so the description does not need to redefine them. The description adds no parameter-specific detail beyond the schema, which keeps it at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns'), resource ('currently-on-sale experiences'), and distinct scope ('within the next few hours', 'seasonal products filtered out', 'ranked by popularity'). This clearly differentiates it from sibling tools like whats_on_tonight or get_whats_on_this_week.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening phrase 'Use this when the user wants something to do within the next few hours' gives a clear triggering condition. It does not explicitly list when-not conditions or name alternatives, but the condition is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transfer_infoARead-onlyIdempotentInspect
Use this when the user is arriving in a supported city and needs transfer guidance from an airport, station, or port to a hotel coordinate. Returns taxi, metro, bus, and train estimates with durations, costs, and directions.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Supported city: London, Paris, New York, Amsterdam, Barcelona, Rome, or Tokyo. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. | |
| from_type | Yes | Arrival hub type. | |
| to_latitude | Yes | Hotel latitude. | |
| to_longitude | Yes | Hotel longitude. |
Output Schema
| Name | Required | Description |
|---|---|---|
| city | No | |
| detail | No | |
| message | No | |
| options | No | |
| from_type | No | |
| error_type | No | |
| distance_km | No | |
| origin_name | No | |
| schema_version | No | |
| hotel_coordinates | No | |
| origin_coordinates | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the behavioral outcome (returns estimates with durations, costs, and directions), which goes beyond annotations and provides useful context for what the agent can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the usage trigger, and the second lists the return content. Every word earns its place, and it is compact enough to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a full output schema, complete parameter descriptions, and safety-related annotations, the description covers the essential trigger, input context, and return content. No critical information needed to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as every parameter (city, format, language, from_type, to_latitude, to_longitude) already has a clear description. The tool description itself adds no additional parameter-level meaning, so the baseline of 3 applies since the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb('use'), resource ('transfer guidance'), and scope ('airport, station, or port to a hotel coordinate'), clearly distinguishing it from sibling tools that focus on experiences or city guides. It also names the output content ('taxi, metro, bus, and train estimates'), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'when the user is arriving in a supported city and needs transfer guidance.' It does not mention when-not-to-use or name an alternative sibling, but there is no overlapping sibling tool, so the clear trigger context is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_travel_tipsARead-onlyIdempotentInspect
Use this to surface bookable experiences relevant to a practical topic in a city, such as transport passes or food tours. It returns a ranked list of experiences (search rows) ONLY: the topic filter is accepted but not yet applied, and the payload contains no tips text, emergency numbers, or phrases. Do not rely on it for actual logistics guidance; answer those questions yourself and use this list for bookable add-ons.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug. | |
| topic | No | Optional topic filter. When omitted, returns a summary across all topics. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| request_id | No | |
| experiences | No | |
| _normalization | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations declaring read-only and idempotent behavior, the description discloses important operational limitations: the topic filter is accepted but not applied, the payload contains no tips or emergency numbers, and only ranked experience search rows are returned. This materially helps an agent set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, behavioral limitation, and usage guidance. The most critical information is front-loaded, and there is no redundant restating of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with a full input schema and an output schema, the description covers purpose, return type, limitations, and how the agent should act. Nothing essential is missing for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying the topic parameter's practical limitation—that it is accepted but not yet applied—and by giving concrete examples like transport passes and food tours, which go beyond the schema's enum labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it surfaces bookable experiences relevant to a practical topic in a city. It clearly distinguishes itself from a logistics/tips tool by emphasizing that it returns only search rows and no tips text or emergency information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: for bookable experiences tied to practical topics. It also explicitly warns not to rely on it for actual logistics guidance, which is a useful exclusion, though it does not name a specific sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_whats_on_this_weekARead-onlyInspect
Use this when the user wants ideas for the coming week in a city. Returns a ranked list of currently on-sale experiences (search rows), not a day-by-day calendar. Assemble any weekly structure yourself and verify specific dates with get_availability.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| request_id | No | |
| experiences | No | |
| _normalization | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and non-destructive behavior, so the description adds value by explaining the tool returns currently on-sale experiences as search rows rather than a calendar. It also warns that dates must be verified elsewhere, which is useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver purpose, output shape, and key caveats in order of importance. Every sentence earns its place, and the most critical usage guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with a rich input schema and an output schema present, the description covers the essential operational knowledge: what is returned, what is not returned, and how to verify dates. No critical gap remains for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with 100% coverage, including city slug, format enum, and language code. The description adds no parameter-level detail, which is acceptable because the schema carries that burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns ranked ideas for the coming week in a city, and explicitly distinguishes itself from a day-by-day calendar. This clearly separates it from sibling tools like get_availability and whats_on_tonight without requiring the agent to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It opens with an explicit 'Use this when the user wants ideas for the coming week in a city' and provides a specific alternative instruction: verify specific dates with get_availability. It also sets expectations by saying the agent must assemble any weekly structure itself, which is a clear when-not/limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_citiesARead-onlyIdempotentInspect
Use this when the user wants to browse supported cities before searching. Returns city names, slugs, country codes, and product counts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of cities to return (1-50). Defaults to 50 when omitted. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| country | No | Optional country code or country name filter. | |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cities | No | |
| detail | No | |
| message | No | |
| error_type | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context by noting the tool returns product counts and is a browsing/pre-search operation, but it does not disclose details like default limit, ordering, or localization behavior beyond what the schema and output schema already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states when to use the tool and what it returns. Every phrase earns its place, with no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only list tool with four fully documented optional parameters and an output schema, the description provides the necessary trigger context and return summary. There are no hidden side effects, required permissions, or complex usage prerequisites to disclose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has its own description, so the baseline is 3. The tool description itself mentions the output fields but adds no extra parameter semantics; the schema handles that burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('browse') and resource ('supported cities') and explicitly positions the tool as a pre-search step, distinguishing it from the many search and recommendation siblings. It also names the return payload (city names, slugs, country codes, product counts), making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use the tool ('when the user wants to browse supported cities before searching'). It doesn't name specific alternative tools or give exclusion criteria, but the phrase 'before searching' adequately guides selection relative to the sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plan_itineraryARead-onlyIdempotentInspect
Use this when the user wants a multi-day plan for a single city. Returns a flat ranked candidate list of experiences (search rows), not structured day slots or a running cost. Arrange the candidates into days yourself and compute totals only from returned price fields.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug. | |
| days | Yes | Number of days to plan (1-7). | |
| pace | No | Itinerary density. relaxed = 1-2 stops per day, packed = 4-5. | |
| budget | No | Budget band per day per person. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| audience | No | Target audience. Currently 'family' is the strongest signal in the catalogue (resolves via the 'family' tag, ~3,200 products). Other values are best-effort and may be sparsely populated; for guaranteed family-suitable results prefer tags=['family'] in addition to or instead of this filter. | |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. | |
| interests | No | Free-text interest seed, e.g., "history, food, river". |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| request_id | No | |
| experiences | No | |
| _normalization | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover the safety profile (readOnly=true, idempotent=true, destructive=false), so the bar is lower. The description adds high-value behavioral disclosure beyond that: the tool does NOT produce the structured plan its name implies, returns unorganized ranked candidates, and requires the caller to perform day-arrangement and cost-totaling itself. Correcting such a name-driven misconception is exactly the kind of context annotations cannot provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences totaling roughly 60 words, delivering purpose, output shape, caller responsibility, and cost-computation instruction in order of importance. Every sentence earns its place and there is zero filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with an output schema, rich per-parameter descriptions, and safety annotations, everything an agent needs to call it correctly is present: scope, output shape, what it deliberately avoids, and required post-processing. The only marginal gap is unnamed siblings for single-day plans, which is a usage-guidelines nuance rather than a completeness failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema already documents each parameter richly (e.g., pace density meanings, audience caveats about sparse population, format json vs text), and the description adds no parameter-specific detail beyond the general instruction to 'compute totals only from returned price fields.' The schema carries the heavy lifting here, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: 'a multi-day plan for a single city.' It goes further by stating exactly what it returns (flat ranked candidate list, not day slots), which sharpens the contrast with siblings like get_family_day or get_date_night even without naming them. The negative framing 'not structured day slots or a running cost' removes any ambiguity an agent might have from the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this when the user wants a multi-day plan for a single city' is explicit when-to-use guidance, and the qualifier 'single city' implicitly rules out multi-city planning tools. The 'not structured day slots' phrase implies when NOT to use it, but it never names a concrete alternative like get_family_day or get_date_night for single-day plans, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_experiencesARead-onlyIdempotentInspect
Use this when the user describes what they want in natural language rather than naming a category. Parses the query for audience, mood, constraints, occasion, and time of day, then returns scored recommendations with a reason field explaining the match.
| Name | Required | Description | Default |
|---|---|---|---|
| pax | No | Number of people. Default 2. | |
| city | No | Optional city slug. If omitted, the city is parsed from the query. | |
| date | No | Optional ISO date (YYYY-MM-DD) for availability-aware ranking. | |
| limit | No | Number of recommendations to return (1-20). Default 5. | |
| query | Yes | Natural-language preference, e.g., "romantic evening in Paris under 100 euros" or "rainy day in Edinburgh with kids 8 and 12". | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| request_id | No | |
| experiences | No | |
| _normalization | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds meaningful behavioral detail beyond the schema: it parses for audience, mood, constraints, occasion, and time of day, and returns scored recommendations with a reason field. This helps the agent anticipate the tool's reasoning and output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The usage trigger is front-loaded, the parse behavior is summarized in a compact list of dimensions, and the output characteristic (scored recommendations with reason field) is included without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety and idempotency, the description is complete enough for tool selection and invocation. It covers the trigger, parse behavior, and result shape. It could more explicitly distinguish from overlapping siblings like compare_experiences or get_date_night, but this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra semantic value by specifying the dimensions parsed from the query (audience, mood, constraints, occasion, time of day), which enriches understanding of the query parameter beyond the schema's examples. This justifies a slight upgrade.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific trigger (user describes desires in natural language), names the tool's action (parses and returns scored recommendations), and distinguishes it from category-based tools by saying 'rather than naming a category.' This makes it clear how recommend_experiences differs from siblings like search_experiences or search_by_mood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description opens with an explicit when-to-use condition: use this tool when the user describes preferences in natural language rather than naming a category. It gives a clear exclusion ('rather than naming a category') but does not name a specific alternative sibling tool, so the guidance is strong but not fully explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_experience_cardsARead-onlyIdempotentInspect
Use this immediately after ANY discovery or search tool (search_experiences, whats_on_tonight, get_last_minute, get_whats_on_this_week, recommend_experiences, search_by_mood, get_hidden_gems, get_family_day, get_date_night, search_local_experiences) returns results. It is the only tool that displays the visual experience cards, so always call it once for every result set you want shown. Take the experience_ids those tools provide and render them; pass the product_id values exactly as returned by those tools, never full product rows. Only experience_ids and render_type are required. Optionally pass render_context.intent_summary (a short phrase describing what the user asked for, e.g. city, date, audience) to set the carousel heading. Call it exactly once per result set, and do not also re-list the experiences as text.
| Name | Required | Description | Default |
|---|---|---|---|
| render_type | Yes | Visual layout requested for the widget. | |
| experience_ids | Yes | The stable product_id values from search_experiences results (the product_id field of each returned row). Pass IDs only, never full product rows. | |
| render_context | No | ||
| idempotency_key | No | Optional UUID. Reuse for identical card render responses within five minutes. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavior beyond annotations: it is the only display tool, pass only product_id values never full rows, call exactly once per result set, and render_context.intent_summary controls the carousel heading. This is useful contextual behavior not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every sentence carries operational weight: when to call, what to pass, how many times, and what not to do. The enumerated list of sibling tools is a bit bulky but serves a concrete routing purpose. It is front-loaded with the most critical timing instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested parameters and an output schema, the description is complete: it covers timing, prerequisites, ID format, required vs optional fields, call frequency, and the no-text-listing constraint. The render_type enum and return behavior are adequately covered by the schema and output schema, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and most parameter semantics are already in the schema, including the instruction to pass IDs only. The description does add a small clarification that render_context.intent_summary sets the carousel heading and emphasizes passing product_id values exactly as returned, but it largely reinforces schema content rather than providing substantial new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: render visual experience cards from discovery/search results. It explicitly names the only rendering tool and distinguishes it from the many search and discovery siblings by saying 'It is the only tool that displays the visual experience cards.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives highly explicit when-to-use guidance: call immediately after any listed discovery or search tool returns results, call exactly once per result set, and do not also re-list experiences as text. It names the trigger tools and provides a clear exclusion, leaving no ambiguity about invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_quality_signalAIdempotentInspect
Use this to push a quality signal back to tickadoo about an experience or recommendation you previously surfaced. Examples: stale availability, a failed click-through, a supplier outage, or misleading content. Requires a real forward-event request_id returned within the last 30 days. Repeating the same signal for the same request is idempotent per caller.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Optional free-text context. Required when signal_type is "other". Do not include PII. | |
| request_id | Yes | The request_id from a forward tool result in the last 30 days. Current format: rq_YYYY_MM_DD_HHMMSS_<12-hex>; legacy 6-hex ids remain valid. | |
| signal_type | Yes | The kind of issue you are reporting. Use "other" only when none of the specific types fit, and always include notes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| recorded | No | |
| signal_id | No | |
| error_type | No | |
| recorded_at | No | |
| signal_type | No | |
| schema_version | No | |
| referenced_request_id | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint, readOnlyHint, and destructiveHint, so the bar is lowered. The description adds useful behavioral context: the 30-day validity window, the requirement for a 'real forward-event' request, and idempotency per caller. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences: purpose, examples, and key constraints. Every sentence adds value, and the most important information is front-loaded. No wasted words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, rich schema, output schema, useful annotations), the description covers purpose, examples, prerequisite, and idempotency. Nothing essential is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself already documents formats, constraints, enums, and special cases (e.g., notes required for 'other', PII exclusion). The description adds no significant parameter-level meaning beyond restating the 30-day requirement already in the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('push') and resource ('quality signal back to tickadoo') with a clear target ('an experience or recommendation you previously surfaced'). Concrete examples clarify the scope, and the operation is clearly distinct from the sibling tools, which are all retrieval/planning/search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool, including concrete scenarios (stale availability, failed click-through, supplier outage, misleading content) and a prerequisite (real forward-event request_id within 30 days). It does not explicitly name alternatives or when-not-to-use cases, but no sibling tool performs a similar function, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_by_moodARead-onlyIdempotentInspect
Use this when the user describes the feeling or vibe they want rather than a category, such as romantic, relaxing, adventurous, family fun, foodie, luxury, or rainy day. Maps the mood to preset search filters and returns matching experiences.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name or slug, e.g. "london", "new-york", or "paris". | |
| mood | Yes | Mood preset. Valid values: adventurous, romantic, relaxing, family_fun, cultural, thrill_seeking, foodie, budget_friendly, luxury, rainy_day. | |
| limit | No | Maximum number of experiences to return (1-50). Defaults to the mood preset size when omitted. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mood | No | |
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| mapped_filters | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, idempotent, and non-destructive behavior. The description adds useful context beyond the schema by revealing that moods are mapped to preset search filters rather than used as free-text search keywords. This is meaningful behavioral information without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with the usage trigger front-loaded and the core behavior stated immediately after. Every sentence earns its place, and there is no redundant detail or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full parameter schema coverage, an output schema, and read-only annotations, the description provides exactly the missing contextual information: when to invoke the tool and what distinguishes it from category-based search. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters clearly. The description adds a few mood examples, but these are also present in the enum. It does not add deeper meaning for city, limit, format, or language beyond the structural schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific trigger ('when the user describes the feeling or vibe they want') and a specific behavior ('Maps the mood to preset search filters and returns matching experiences'). It distinguishes itself from category-based search, which separates it from sibling tools like search_experiences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool: when the user describes a feeling or vibe rather than a category. The examples help an agent identify the right call, but it does not explicitly name an alternative tool or state when not to use it, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_experiencesARead-onlyIdempotentInspect
Use this when the user names a city plus a category, query, or filter set and wants a ranked list of bookable experiences. query matches on experience NAME (and venue), so it suits a title or keyword ("Lion King", "river cruise"); for mood or theme use search_by_mood, and for a free-text "what should I do" ask use recommend_experiences. When a query matches no name, results are the city top-picks flagged match_type "fallback_city_ranked" (reason_codes include "fallback_no_text_match") rather than a genuine match, so treat those as suggestions, not the thing asked for. Returns products each with a stable product_id, plus name, slug, city, category, price, rating, review count, and tags. To show the results as visual cards, pass the product_id values from these results into render_experience_cards (experience_ids). Pair with get_experience_details for richer fields.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City slug, e.g., "london", "new-york", "paris". | |
| tags | No | Filter by experience tags. Multiple tags are AND-combined (every tag must match) so adding more tags narrows the result set. Use lowercase singular forms; matching is substring-based against the tag array. The canonical tag taxonomy in the catalogue, ordered by frequency, is: 'tour', 'attraction', 'historical', 'outdoor', 'museum', 'family', 'landmark', 'adventure', 'show', 'indoor', 'food & drink', 'transport', 'theatre', 'concert', 'theme park', 'cruise', 'nightlife', 'comedy', 'musical', 'city pass', 'sport', 'dance', 'aquarium', 'zoo', 'gallery', 'opera', 'wellness', 'water park', 'workshop', 'religious', 'festival'. Examples: ['museum'] for museums; ['family','indoor'] for indoor family attractions; ['outdoor','adventure'] for outdoor adventure activities. Other free-form values may match by substring but are not guaranteed. | |
| limit | No | Number of results to return (1-50). Default 10. | |
| query | No | Free-text query matched against experience name and venue (not description). Split into words that must all match, so it suits a title or keyword; a query that matches no name returns city top-picks flagged match_type "fallback_city_ranked". | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| category | No | Category slug, e.g., "theatre", "tours", "museums", "attractions". | |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. | |
| max_price | No | Maximum price per person in the listed currency. A positive value applies a cap; 0 (or unset) means no price cap (unbounded). | |
| min_rating | No | Minimum aggregate rating on a 0-5 scale. | |
| popular_only | No | DEPRECATED: use restrict_to_top_rated. Alias for the destructive top-rated filter (rating >= 4.5 AND review_count >= 100). The name implies a sort hint but it is a hard WHERE clause. Existing callers continue to work unchanged. | |
| indoor_outdoor | No | Setting filter. 'indoor' / 'outdoor' resolve via the products.tags column (~2,100 indoor and ~5,000 outdoor products are tagged in the catalogue). 'either' applies no filter. | |
| min_review_count | No | Minimum number of customer reviews. Use to filter out new or sparsely-reviewed products. | |
| restrict_to_top_rated | No | DESTRUCTIVE FILTER. When true, hard-restricts results to products with rating >= 4.5 AND review_count >= 100. This is a WHERE clause, not a sort hint. Anything failing the floor is dropped from the result set entirely. Use only when the caller genuinely wants to exclude lower-rated or lesser-reviewed products. For ranking-by-popularity without exclusion, do not set this; results are already ordered by rating and review count. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| request_id | No | |
| experiences | No | |
| _normalization | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as read-only and idempotent, and the description adds meaningful behavioral context beyond that: query matching is name/venue only, no-match results return fallback_city_ranked with reason_codes, and restrict_to_top_rated is highlighted as a destructive WHERE clause despite the tool-level readOnlyHint. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place: trigger conditions, query semantics, fallback behavior, return fields, and chaining suggestions. It is front-loaded with the core use case and remains compact relative to the tool's 13 parameters and its need to disambiguate from many siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with many optional filters and a wide sibling set, the description covers the key decision points: when to call it, what query matches, how fallback results are flagged, what fields are returned, and how to follow up. The output schema exists, so return-value documentation does not need to be repeated in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains each parameter in detail, so the baseline is 3. The tool description mostly reinforces query semantics and output usage rather than adding new parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific trigger ('user names a city plus a category, query, or filter set') and a specific outcome ('ranked list of bookable experiences'), clearly stating the verb and resource. It also explicitly differentiates from search_by_mood and recommend_experiences, so an agent can distinguish this tool without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exactly when to use the tool, names alternatives for different user intents ('search_by_mood' for mood/theme, 'recommend_experiences' for free-text suggestions), and explains the fallback behavior. It also chains to render_experience_cards and get_experience_details, giving clear next-step guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_local_experiencesARead-onlyIdempotentInspect
Use this when the user mentions a place, neighbourhood, landmark, or area but does not give exact coordinates. Examples: 'near the Louvre', 'in Trastevere', 'around Times Square', "walking distance from St Paul's Cathedral". Returns experiences matched first by exact venue/neighbourhood, then by city centre fallback. Do not use for general city-wide search; use search_experiences for that.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City slug or name to disambiguate. Recommended for any place_hint that could exist in multiple cities. | |
| tags | No | Filter by experience tags. Multiple tags are AND-combined (every tag must match) so adding more tags narrows the result set. Use lowercase singular forms; matching is substring-based against the tag array. The canonical tag taxonomy in the catalogue, ordered by frequency, is: 'tour', 'attraction', 'historical', 'outdoor', 'museum', 'family', 'landmark', 'adventure', 'show', 'indoor', 'food & drink', 'transport', 'theatre', 'concert', 'theme park', 'cruise', 'nightlife', 'comedy', 'musical', 'city pass', 'sport', 'dance', 'aquarium', 'zoo', 'gallery', 'opera', 'wellness', 'water park', 'workshop', 'religious', 'festival'. Examples: ['museum'] for museums; ['family','indoor'] for indoor family attractions; ['outdoor','adventure'] for outdoor adventure activities. Other free-form values may match by substring but are not guaranteed. | |
| limit | No | ||
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| date_to | No | ||
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. | |
| date_from | No | ||
| place_hint | Yes | Free-text place reference: a landmark, neighbourhood, monument, station, or street name. E.g. 'Louvre Museum', 'Trastevere', 'Soho', 'Times Square'. Required. | |
| radius_hint | No | Optional: how broadly to interpret the place_hint. 'walking' is ~1km, 'short_drive' is ~5km, 'city_wide' falls back to the whole city. Default 'walking'. | |
| neighbourhood | No | Optional: a known neighbourhood within the city to narrow results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| request_id | No | |
| experiences | No | |
| _normalization | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the matching-order behaviour (exact venue/neighbourhood first, then city centre fallback) and the constraint that exact coordinates are not required, which is useful behavioural context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short, information-dense sentences with no filler: the trigger condition, examples, matching behaviour, and the exclusion/redirect each earn their place. The most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool, the description covers the core trigger, the main required argument, and the key fallback logic, while the output schema and existing per-parameter descriptions carry the rest. It omits details about how limit/tags/radius_hint interact, but those are documented in the schema or are non-critical for selecting the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 70% of parameters with descriptions, including place_hint, city, tags, format, and radius_hint; the description's examples reinforce the free-text nature of place_hint but do not add meaning beyond the schema. It does not clarify undocumented parameters like limit, date_from, or date_to, so it adds limited parameter-level value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with an explicit usage condition ('when the user mentions a place, neighbourhood, landmark, or area but does not give exact coordinates') and names the sibling tool it is not (search_experiences), so an agent can immediately distinguish it from general city-wide search. The fallback behaviour ('matched first by exact venue/neighbourhood, then by city centre fallback') further specifies the resource and logic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('Use this when...'), concrete examples ('near the Louvre', 'in Trastevere'), and an explicit exclusion with a redirect: 'Do not use for general city-wide search; use search_experiences for that.' This fully instructs when to select this tool versus the primary alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whats_on_tonightARead-onlyInspect
Use this when the user asks what is on in a city tonight. Returns evening-appropriate experiences currently on sale, with out-of-season products filtered out, evening-led options ranked first, and multi-day passes, travel cards and transport products ranked last. Top results carry start_time (venue-local) when the live supplier calendar confirms a performance in the evening window (late afternoon onward); a confirmed slot lifts a row, and timed rows sort soonest-first within one relevance band. Rows without start_time have no confirmed evening time. Confirm the selected experience with get_availability before stating it is bookable tonight.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug. | |
| format | No | Response shape. 'json' returns structured records; 'text' returns the same content rendered as a short narrative paragraph for chat surfaces. | json |
| category | No | Optional category slug to narrow results. | |
| language | No | BCP-47 language code for human-readable fields (e.g., 'en', 'fr-FR'). Defaults to English when omitted. | |
| max_results | No | Default 10, max 30. |
Output Schema
| Name | Required | Description |
|---|---|---|
| detail | No | |
| message | No | |
| results | No | |
| error_type | No | |
| pagination | No | |
| request_id | No | |
| experiences | No | |
| _normalization | No | |
| schema_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses behavior beyond the annotations: out-of-season filtering, evening-led ranking, multi-day passes/transport ranked last, start_time presence meaning a confirmed live-supplier evening slot, and the sort semantics within a relevance band. It also explains what missing start_time means, which is critical for correct interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: the trigger, the ranking behavior, the start_time semantics, and the required confirmation step. The description is dense but not bloated, and the most important usage condition is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return structure is covered externally. The description supplies the query intent, ranking/filtering rules, a caveat about unconfirmed times, and a mandatory next step. An agent has enough information to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter meaning is already fully documented in the input schema. The description adds context about the tool's overall behavior but does not need to repeat parameter details. This meets the baseline for a fully covered schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns evening-appropriate experiences for a city tonight. It clearly differentiates from siblings like get_whats_on_this_week by anchoring on 'tonight' and the user's 'what is on' intent. The scope is further sharpened by filtering and ranking constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit trigger condition: 'Use this when the user asks what is on in a city tonight.' It also tells the agent to follow up with get_availability before confirming bookability. It does not enumerate when to prefer sibling tools like get_whats_on_this_week or search_experiences, so it falls just short of a 5.
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
search_experiences1 field changed- changed
Input schema / properties / query / descriptionPrevious value: -"Free-text query matched against experience name and venue (not description). Split into words that must all match, so it is best for a title or keyword; a query that matches no name returns city top-picks flagged match_type \"fallback_city_ranked\"."New value: +"Free-text query matched against experience name and venue (not description). Split into words that must all match, so it suits a title or keyword; a query that matches no name returns city top-picks flagged match_type \"fallback_city_ranked\"."
23 tool updates
- Changed
check_availability1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "available": { + "type": "boolean" + }, + "date": { + "type": "string" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "message": { + "type": "string" + }, + "schema_version": { + "type": "string" + }, + "slots": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "slug": { + "type": "string" + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "total_for_party": { + "additionalProperties": true, + "type": "object" + } + }, + "type": "object" +}
- Changed
compare_experiences1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "comparison": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "differences": { + "items": { + "type": "string" + }, + "type": "array" + }, + "error_type": { + "type": "string" + }, + "message": { + "type": "string" + }, + "schema_version": { + "type": "string" + }, + "text": { + "type": "string" + }, + "winner": { + "additionalProperties": true, + "type": "object" + } + }, + "type": "object" +}
- Changed
find_nearby_experiences1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "_normalization": { + "additionalProperties": true, + "type": "object" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "experiences": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + }, + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "offset": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "request_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
get_availability1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "book_now_confidence": { + "type": "integer" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "inventoryLevel": { + "additionalProperties": true, + "type": "object" + }, + "message": { + "type": "string" + }, + "next_available": { + "type": [ + "string", + "null" + ] + }, + "product_id": { + "type": "string" + }, + "provenance_level": { + "type": "string" + }, + "schema_version": { + "type": "string" + }, + "slots": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "slug": { + "type": "string" + }, + "timezone": { + "type": "string" + }, + "total_slots": { + "type": "integer" + } + }, + "type": "object" +}
- Changed
get_city_guide1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "_normalization": { + "additionalProperties": true, + "type": "object" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "experiences": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + }, + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "offset": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "request_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
get_date_night1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "_normalization": { + "additionalProperties": true, + "type": "object" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "experiences": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + }, + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "offset": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "request_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
get_experience_details1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "message": { + "type": "string" + }, + "product": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "products": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
get_family_day1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "_normalization": { + "additionalProperties": true, + "type": "object" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "experiences": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + }, + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "offset": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "request_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
get_hidden_gems1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "_normalization": { + "additionalProperties": true, + "type": "object" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "experiences": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + }, + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "offset": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "request_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
get_last_minute1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "_normalization": { + "additionalProperties": true, + "type": "object" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "experiences": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + }, + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "offset": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "request_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
get_related_experiences1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "context": { + "type": "string" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "message": { + "type": "string" + }, + "related": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": "string" + }, + "edge_strength": { + "type": "number" + }, + "edge_type": { + "type": "string" + }, + "name": { + "type": "string" + }, + "price": { + "type": [ + "number", + "null" + ] + }, + "product_id": { + "type": "string" + }, + "slug": { + "type": "string" + }, + "title": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + }, + "source_id": { + "type": "string" + }, + "total": { + "type": "integer" + } + }, + "type": "object" +}
- Changed
get_transfer_info1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "city": { + "type": "string" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "distance_km": { + "type": "number" + }, + "error_type": { + "type": "string" + }, + "from_type": { + "type": "string" + }, + "hotel_coordinates": { + "additionalProperties": true, + "type": "object" + }, + "message": { + "type": "string" + }, + "options": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "origin_coordinates": { + "additionalProperties": true, + "type": "object" + }, + "origin_name": { + "type": "string" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
get_travel_tips1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "_normalization": { + "additionalProperties": true, + "type": "object" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "experiences": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + }, + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "offset": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "request_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
get_whats_on_this_week1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "_normalization": { + "additionalProperties": true, + "type": "object" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "experiences": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + }, + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "offset": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "request_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
list_cities1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "cities": { + "items": { + "additionalProperties": true, + "properties": { + "city": { + "type": "string" + }, + "country": { + "type": "string" + }, + "country_code": { + "type": "string" + }, + "product_count": { + "type": "integer" + }, + "slug": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "message": { + "type": "string" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
plan_itinerary1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "_normalization": { + "additionalProperties": true, + "type": "object" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "experiences": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + }, + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "offset": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "request_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
recommend_experiences1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "_normalization": { + "additionalProperties": true, + "type": "object" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "experiences": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + }, + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "offset": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "request_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
render_experience_cards4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / oneOfAdded value: +[ + { + "additionalProperties": true, + "properties": { + "experience_ids": { + "description": "The stable product ids rendered as cards.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "experience_ids" + ], + "type": "object" + }, + { + "additionalProperties": true, + "properties": { + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "enum": [ + "ambiguous_input", + "invalid_input", + "rate_limited", + "supplier_unavailable", + "circuit_breaker_open", + "partial_result", + "unauthorized", + "forbidden", + "internal_error", + "not_found" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "retry_after": { + "type": "string" + }, + "retry_after_seconds": { + "minimum": 0, + "type": "integer" + }, + "schema_version": { + "const": "https://mcp.tickadoo.com/schemas/tool_error/1.0" + } + }, + "required": [ + "schema_version", + "error_type", + "message", + "detail" + ], + "type": "object" + } +] - removed
Output schema / propertiesRemoved value: -{ - "experience_ids": { - "description": "The stable product ids rendered as cards.", - "items": { - "type": "string" - }, - "type": "array" - } -} - removed
Output schema / requiredRemoved value: -[ - "experience_ids" -]
- Changed
report_quality_signal1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "message": { + "type": "string" + }, + "recorded": { + "type": "boolean" + }, + "recorded_at": { + "type": "string" + }, + "referenced_request_id": { + "type": "string" + }, + "schema_version": { + "type": "string" + }, + "signal_id": { + "type": "string" + }, + "signal_type": { + "type": "string" + } + }, + "type": "object" +}
- Changed
search_by_mood1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "mapped_filters": { + "additionalProperties": true, + "type": "object" + }, + "message": { + "type": "string" + }, + "mood": { + "type": "string" + }, + "pagination": { + "additionalProperties": true, + "type": "object" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
search_experiences13 fields changed- added
Output schema / properties / _normalizationAdded value: +{ + "additionalProperties": true, + "type": "object" +} - added
Output schema / properties / detailAdded value: +{ + "additionalProperties": true, + "type": "object" +} - added
Output schema / properties / error_typeAdded value: +{ + "type": "string" +} - added
Output schema / properties / experiencesAdded value: +{ + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / messageAdded value: +{ + "type": "string" +} - added
Output schema / properties / pagination / properties / offsetAdded value: +{ + "type": "integer" +} - added
Output schema / properties / request_idAdded value: +{ + "type": "string" +} - removed
Output schema / properties / results / descriptionRemoved value: -"Ranked bookable experiences." - removed
Output schema / properties / results / items / properties / name / descriptionRemoved value: -"Display name of the experience." - changed
Output schema / properties / results / items / properties / product_id / descriptionPrevious value: -"Stable identifier for this experience. Pass these values into render_experience_cards (experience_ids) to show the results as visual cards."New value: +"Stable experience identifier for detail, availability, related-experience, and card-rendering calls." - added
Output schema / properties / results / items / properties / tagsAdded value: +{ + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / results / items / properties / venueAdded value: +{ + "type": "string" +} - added
Output schema / properties / schema_versionAdded value: +{ + "type": "string" +}
- Changed
search_local_experiences1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "_normalization": { + "additionalProperties": true, + "type": "object" + }, + "detail": { + "additionalProperties": true, + "type": "object" + }, + "error_type": { + "type": "string" + }, + "experiences": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "message": { + "type": "string" + }, + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "offset": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "request_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "schema_version": { + "type": "string" + } + }, + "type": "object" +}
- Changed
whats_on_tonight13 fields changed- added
Output schema / properties / _normalizationAdded value: +{ + "additionalProperties": true, + "type": "object" +} - added
Output schema / properties / detailAdded value: +{ + "additionalProperties": true, + "type": "object" +} - added
Output schema / properties / error_typeAdded value: +{ + "type": "string" +} - added
Output schema / properties / experiencesAdded value: +{ + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable experience identifier for detail, availability, related-experience, and card-rendering calls.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "venue": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / messageAdded value: +{ + "type": "string" +} - added
Output schema / properties / pagination / properties / offsetAdded value: +{ + "type": "integer" +} - added
Output schema / properties / request_idAdded value: +{ + "type": "string" +} - removed
Output schema / properties / results / descriptionRemoved value: -"Ranked bookable experiences." - removed
Output schema / properties / results / items / properties / name / descriptionRemoved value: -"Display name of the experience." - changed
Output schema / properties / results / items / properties / product_id / descriptionPrevious value: -"Stable identifier for this experience. Pass these values into render_experience_cards (experience_ids) to show the results as visual cards."New value: +"Stable experience identifier for detail, availability, related-experience, and card-rendering calls." - added
Output schema / properties / results / items / properties / tagsAdded value: +{ + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / results / items / properties / venueAdded value: +{ + "type": "string" +} - added
Output schema / properties / schema_versionAdded value: +{ + "type": "string" +}
1 tool update
- Changed
search_experiences1 field changed- changed
Input schema / properties / query / descriptionPrevious value: -"Free-text query matched against title, venue, and description."New value: +"Free-text query matched against experience name and venue (not description). Split into words that must all match, so it is best for a title or keyword; a query that matches no name returns city top-picks flagged match_type \"fallback_city_ranked\"."
1 tool update
- Changed
report_quality_signal2 fields changed- changed
Input schema / properties / request_id / descriptionPrevious value: -"The request_id from a forward tool result in the last 30 days. Format: rq_YYYY_MM_DD_HHMMSS_<6-hex>."New value: +"The request_id from a forward tool result in the last 30 days. Current format: rq_YYYY_MM_DD_HHMMSS_<12-hex>; legacy 6-hex ids remain valid." - changed
Input schema / properties / request_id / patternPrevious value: -"^rq_\\d{4}_\\d{2}_\\d{2}_\\d{6}_[0-9a-f]{6}$"New value: +"^rq_\\d{4}_\\d{2}_\\d{2}_\\d{6}_(?:[0-9a-f]{6}|[0-9a-f]{12})$"
1 tool update
- Changed
report_quality_signal1 field changed- changed
Input schema / properties / request_id / descriptionPrevious value: -"The request_id from a prior tool result you are reporting a signal against. Format: rq_YYYY_MM_DD_HHMMSS_<6-hex>."New value: +"The request_id from a forward tool result in the last 30 days. Format: rq_YYYY_MM_DD_HHMMSS_<6-hex>."
1 tool update
- Changed
render_experience_cards1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "experience_ids": { + "description": "The stable product ids rendered as cards.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "experience_ids" + ], + "type": "object" +}
2 tool updates
- Changed
search_experiences1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "results": { + "description": "Ranked bookable experiences.", + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "description": "Display name of the experience.", + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable identifier for this experience. Pass these values into render_experience_cards (experience_ids) to show the results as visual cards.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
whats_on_tonight1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "pagination": { + "additionalProperties": true, + "properties": { + "limit": { + "type": "integer" + }, + "total": { + "type": "integer" + } + }, + "type": "object" + }, + "results": { + "description": "Ranked bookable experiences.", + "items": { + "additionalProperties": true, + "properties": { + "booking_url": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": "string" + }, + "city": { + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "description": "Display name of the experience.", + "type": "string" + }, + "price": { + "additionalProperties": true, + "properties": { + "amount_minor": { + "type": "integer" + }, + "currency": { + "type": "string" + }, + "display": { + "type": "string" + } + }, + "type": "object" + }, + "product_id": { + "description": "Stable identifier for this experience. Pass these values into render_experience_cards (experience_ids) to show the results as visual cards.", + "type": "string" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "review_count": { + "type": [ + "integer", + "null" + ] + }, + "slug": { + "type": "string" + } + }, + "required": [ + "product_id", + "name" + ], + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
1 tool update
- Changed
search_experiences2 fields changed- changed
Input schema / properties / popular_only / descriptionPrevious value: -"DEPRECATED — use restrict_to_top_rated. Alias for the destructive top-rated filter (rating >= 4.5 AND review_count >= 100). The name implies a sort hint but it is a hard WHERE clause. Existing callers continue to work unchanged."New value: +"DEPRECATED: use restrict_to_top_rated. Alias for the destructive top-rated filter (rating >= 4.5 AND review_count >= 100). The name implies a sort hint but it is a hard WHERE clause. Existing callers continue to work unchanged." - changed
Input schema / properties / restrict_to_top_rated / descriptionPrevious value: -"DESTRUCTIVE FILTER. When true, hard-restricts results to products with rating >= 4.5 AND review_count >= 100. This is a WHERE clause, not a sort hint — anything failing the floor is dropped from the result set entirely. Use only when the caller genuinely wants to exclude lower-rated or lesser-reviewed products. For ranking-by-popularity without exclusion, do not set this; results are already ordered by rating and review count."New value: +"DESTRUCTIVE FILTER. When true, hard-restricts results to products with rating >= 4.5 AND review_count >= 100. This is a WHERE clause, not a sort hint. Anything failing the floor is dropped from the result set entirely. Use only when the caller genuinely wants to exclude lower-rated or lesser-reviewed products. For ranking-by-popularity without exclusion, do not set this; results are already ordered by rating and review count."
3 tool updates
- Changed
list_cities1 field changed- added
Input schema / properties / limitAdded value: +{ + "description": "Maximum number of cities to return (1-50). Defaults to 50 when omitted.", + "maximum": 50, + "minimum": 1, + "type": "integer" +}
- Changed
search_by_mood1 field changed- added
Input schema / properties / limitAdded value: +{ + "description": "Maximum number of experiences to return (1-50). Defaults to the mood preset size when omitted.", + "maximum": 50, + "minimum": 1, + "type": "integer" +}
- Changed
search_experiences1 field changed- changed
Input schema / properties / max_price / descriptionPrevious value: -"Maximum price per person in the listed currency."New value: +"Maximum price per person in the listed currency. A positive value applies a cap; 0 (or unset) means no price cap (unbounded)."
1 tool update
- Changed
get_availability1 field changed- changed
Input schema / properties / date_to / descriptionPrevious value: -"End date in YYYY-MM-DD. Defaults to today plus 14 days and is capped to a 365-day window."New value: +"End date in YYYY-MM-DD. Defaults to 14 days after date_from and is capped to a 365-day window."
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 & compare prices for tours, activities and tickets across multiple providers.
Search tours, attraction tickets, and holiday packages across 24 countries.
Search and book last-minute tours and activities in 28 cities from 21 suppliers.
Discover and book 5,000+ curated local experiences across 500 US destinations.
Related MCP Servers
- AlicenseAqualityFmaintenanceReal-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.41MIT
- -
- 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+ property221MIT
- AlicenseAqualityBmaintenanceProvides music events, concerts, music festivals, nightclubs and other events information.172MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
Many tools overlap heavily. search_experiences, search_by_mood, recommend_experiences, search_local_experiences, and find_nearby_experiences all return ranked experience lists with only slightly different input axes. Curated list tools like get_date_night, get_family_day, get_hidden_gems, get_last_minute, get_whats_on_this_week, and whats_on_tonight are also nearly indistinguishable in output shape and purpose, just with different filters. check_availability and get_availability clearly duplicate availability checking
The overwhelming majority follow a clear verb_noun pattern (get_experience_details, search_by_mood, list_cities, plan_itinerary). Minor deviations like whats_on_tonight (missing 'get') and check_availability versus get_availability are small inconsistencies but do not cause confusion
23 tools is on the heavy side for an experience-discovery and booking-assistant server. The count is justified by many curated scenarios, but several tools could be consolidated (e.g., all the list-based get_* and whats_on_* tools could be one parameterized tool). It is not excessive enough to be a major problem
The domain of discovering and checking availability for experiences is well covered: search, filter by mood/place/natural language, get details, check availability, compare, get related items, and find transportation. However, there are notable gaps: get_travel_tips returns only experience rows despite claiming tips, get_city_guide similarly returns a limited payload, and there is no tool for actual booking/reservation (though the booking link may be external). The legacy check_availability seems redundant