HotelsCasa

Search tickets and tours

search_activities

Read-onlyIdempotent

Search tickets, tours and attractions (museums, monuments, day trips) sold on HotelsCasa with our partner Tiqets. Search by city (its name in any language works: Istanbul, İstanbul, Estambul, Стамбул), by ISO country code or by text. With no arguments returns the cities with the most activities. The answer carries total (how many activities match in all), count (how many are on this page, 10 at most) and matched_cities when a city was recognised. Prices are per person in EUR, "from". Tickets are bought on the activity page. Always give the traveller the url of every item as a clickable link, unchanged: it is the only way to book or buy.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No	City name in any language, e.g. Istanbul, Стамбул, Rome, Roma.
`lang`	No	Language of the answer and of the links: es, en, de, fr, it, pt, tr or ru. Default es.
`page`	No
`sort`	No
`limit`	No	How many results to return (1-10, default 10).
`query`	No	Text in the title, e.g. Sagrada Familia, Colosseum.
`country`	No	ISO-3166 alpha-2, e.g. TR, IT, BR. Can be combined with city.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`page`	No
`count`	No
`error`	No
`items`	No
`total`	No
`cities`	No
`message`	No
`next_page`	No
`matched_cities`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 30, 2026

addedInput schema / properties / city / description

Added value: +"City name in any language, e.g. Istanbul, Стамбул, Rome, Roma."

changedInput schema / properties / country / description

Previous value: -"ISO-3166 alpha-2, e.g. ES, IT."New value: +"ISO-3166 alpha-2, e.g. TR, IT, BR. Can be combined with city."

addedOutput schema / properties / matched_cities

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "properties": {},
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / total
```
Added value: +{
+  "type": "integer"
+}
```

First observedSep 19, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare this read-only, idempotent, non-destructive and closed-world. The description goes beyond them with real operational context: page size cap of 10, price unit and currency ('per person in EUR, from'), and the critical booking constraint that tickets are purchased on the activity page so the URL must be passed through unchanged. It does not discuss rate limits or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what is searched and where, then filtering modes, then the empty-argument behavior, then response and pricing notes, ending on the booking constraint. Dense but every sentence carries information an agent needs to call or report correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, open-search tool with an output schema, the description covers filtering modes, defaults, pagination cap, response fields, currency semantics, and the downstream booking workflow. Nothing an agent needs to invoke it or handle its results is missing, and return-value detail is largely delegated to the output schema as expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 71%, above the baseline where the schema carries most weight. The description groups the filtering modes (city/country/text) and notes multilingual city input, but adds little beyond the schema's own city example, and leaves 'page' and 'sort' semantics entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Search tickets, tours and attractions... sold on HotelsCasa with our partner Tiqets') and scopes it in a way that separates it from siblings like search_hotels, search_properties and get_activity. The supplier and inventory relationship adds precision a generic 'search' would lack.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear selection conditions – search by city name (any language), ISO country code, or free text – and defines the no-argument fallback (cities with the most activities). It stops short of explicitly contrasting itself with get_activity (detail lookup) or naming when NOT to call it, so it is clear context rather than full routing guidance.

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

All HotelsCasa tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.