Skip to main content
Glama

Search Storied Collection venues

search_venues
Read-only

Search Storied Collection's historic exclusive-use venues (castles, estates, châteaux in Scotland, England, Wales, Ireland, France). All filters are optional and combined with AND. Prices are 'pricing from' per night in the venue's native currency (GBP or EUR) and are NEVER converted — max_price only matches venues priced in the given currency (default: any currency, compared numerically within each venue's own currency; pass max_price_currency to be precise). Venues with price 'On request' are excluded when max_price is set. Boolean filters exclude venues where the value is unknown. Returns a summary list; use get_venue for full details.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_venues"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNoFree-text match on venue name or country, e.g. 'castle', 'chateau', 'Gordon'
countryNoCountry name, e.g. Scotland, England, Wales, Ireland, France (case-insensitive)
helipadNotrue = must have a helipad; false = must not
sort_byNoSort order (price ascending, sleeps descending, name A–Z). Default name.
max_priceNoMaximum 'pricing from' amount in max_price_currency
min_sleepsNoMinimum number of guests the venue sleeps
ev_chargingNotrue = must have electric car charging; false = must not
guest_houseNotrue = must have a guest house; false = no guest house
max_minimum_nightsNoOnly venues whose minimum stay is at most this many nights
max_price_currencyNoCurrency of max_price. Only venues priced in this currency are returned. No conversion is performed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Well beyond the readOnly/openWorld annotations, it discloses non-obvious matching behavior: prices are 'pricing from' per night, never converted, 'On request' venues are dropped when max_price is set, and boolean filters exclude venues with unknown values. These are exactly the traps an agent would otherwise hit.

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?

Five dense sentences with the scope first, then the filtering rules, then the sibling routing. No filler; the parentheticals carry real constraints rather than decoration.

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?

Ten optional params and no output schema, yet the description covers the return shape ('summary list'), the filter combination logic, and the price-model edge cases. Nothing an agent needs in order to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description still earns above that by clarifying the cross-currency semantics of max_price (numeric comparison within each venue's own currency by default, max_price_currency for precision). It leaves query, min_sleeps and sort_by to the schema, which documents them adequately.

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?

Specific verb ('Search') plus a precisely scoped resource ('Storied Collection's historic exclusive-use venues') with geography enumerated. The final sentence explicitly positions it against the sibling get_venue by stating this returns a summary list.

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?

States that all filters are optional and AND-combined, and gives a clear routing rule: use get_venue for full details. No explicit guidance on when not to use it or how it relates to list_countries, though the countries are enumerated inline so that routing is less necessary.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.