Domus Aedes

Search Domus Aedes properties

search_properties

Read-onlyIdempotent

Searches Domus Aedes' own portfolio of properties to buy, rent long-term, or stay in (short-term) across Spain and Morocco. Returns up to six best matches for the criteria, whether more matches exist, and refinement suggestions (budget, area, bedrooms, features) that narrow the search. Budgets are EUR: total price for buy, per month for rent, per night for stay. Give check_in/check_out for live availability and a stay total. A stay search our own portfolio cannot serve returns no results and a concierge referral (concierge.domusaedes.com).

Tool call template

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

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

Input Schema

Name	Required	Description
`guests`	No	Number of guests (stay only)
`intent`	Yes	buy = purchase · rent = long-term monthly let · stay = short-term holiday stay with live availability
`check_in`	No	YYYY-MM-DD (stay only)
`features`	No	Required features; every listed feature must be present
`language`	No	Language of the person (labels, summaries and messages come back in it). Default en
`location`	No	City, area or country in the person's words, e.g. "Marbella", "Puerto Banús", "Marrakech", "Costa del Sol", "Catalonia", "Spain"
`check_out`	No	YYYY-MM-DD (stay only)
`budget_max`	No	EUR, inclusive. buy = total price · rent = per month · stay = per night
`budget_min`	No	EUR. buy = total price · rent = per month · stay = per night
`bedrooms_min`	No	Minimum bedrooms
`property_type`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds substantial behavior beyond them: a cap of six best matches, a flag for further matches, refinement suggestions, per-intent budget semantics, and a documented fallback referral when stay inventory is unavailable.

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

Conciseness4/5

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

Four sentences, front-loaded with purpose and scope, then returns, then budget units, then the stay fallback. Dense but each sentence carries information; the budget sentence partially restates schema text but earns its place as reinforcement.

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?

With 11 parameters and no output schema, the description must explain the return shape, and it does (up to six matches, whether more exist, refinement suggestions). It also covers the edge case of an unservable stay search, leaving little an agent needs to know before calling.

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 91%, so the schema carries most parameter documentation and the baseline would be 3. The description adds value by pinning budget interpretation to intent (total price vs per month vs per night) and by pairing check_in/check_out with live availability, which is a cross-parameter dependency the schema does not state.

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?

States a specific verb and resource ('Searches Domus Aedes' own portfolio of properties') plus scope (buy, long-term rent, short-term stay across Spain and Morocco). The 'own portfolio' framing and the search-vs-detail distinction implicitly separate it from get_property and request_property_details.

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?

Gives clear context for use: pass check_in/check_out for live availability and a stay total, use EUR budgets by intent. It also explains the failure path (a stay request the portfolio cannot serve yields no results plus a concierge referral). It does not explicitly contrast with the sibling detail tools, so 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.

All Domus Aedes tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?