PropertyList: Spanish Property MLS

Area market summary

area_market_summary

Read-onlyIdempotent

Return aggregate market context for a Spanish area: number of active listings, median price, mean price, median €/m², and the count broken down by bedroom band. Filterable by property type and search type (for-sale / for-rent / holiday-rentals). Use this before recommending a price or commenting on whether a listing is good value.

If the place name is not one we hold, the response says so (error: location_not_found, location_match.matched: false) and returns no figures. Figures are NEVER nationwide fallbacks.

Price figures follow the search type and are labelled with price_unit: sale prices are totals, for-rent is per MONTH and holiday-rentals is per WEEK. median_price_per_sqm is reported for sales only.

The oracle block carries the attested transaction price for the area. Check oracle.verified before citing it as verified: it is true only for Spanish figures from the notarial register (Consejo General del Notariado) with at least 10 recorded transactions behind them. Outside Spain the figure comes from a national house-price index, carries no transaction count, and must never be described as notary-backed - oracle.source names the real source and oracle.note says why it is not verified.

Transactions are recorded per municipality, so a sub-area (Sotogrande, Puerto Banus, Nueva Andalucia, Orihuela Costa) is answered with the figure for the municipality containing it, with oracle.rolled_up_from_sub_area true and oracle.municipality / oracle.municipality_code naming it. Quote it as the municipality's figure, never as the sub-area's own.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`location`	Yes	Place name (city, suburb, or urbanisation). e.g. 'Marbella'.
`search_type`	No		for-sale
`property_types`	No	Optional comma-separated slugs: apartments, villas, penthouses, plots, townhouses.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	No
`error`	No
`oracle`	Yes
`location`	Yes
`max_price`	No
`min_price`	No
`mean_price`	No
`price_unit`	No
`price_basis`	No
`search_type`	No
`median_price`	No
`location_match`	No
`property_types`	No
`total_listings`	Yes
`by_bedroom_band`	No
`median_price_per_sqm`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedSep 10, 2026
- addedOutput schema / properties / oracle / properties / minimum_verified_sample
```
Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / oracle / properties / municipality
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / oracle / properties / municipality_code
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / oracle / properties / note
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / oracle / properties / requested_area
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / oracle / properties / rolled_up_from_sub_area
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / oracle / properties / source_label
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / oracle / properties / transaction_backed
```
Added value: +{
+  "type": "boolean"
+}
```

Changed5 schema fields changedJul 28, 2026

addedOutput schema / properties / error

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / location_match

Added value: +{
+  "properties": {
+    "exact": {
+      "type": "boolean"
+    },
+    "matched": {
+      "type": "boolean"
+    },
+    "matched_areas": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "matched_location": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "requested": {
+      "type": "string"
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / note

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / price_basis
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / price_unit

Added value: +{
+  "enum": [
+    "total",
+    "per_month",
+    "per_week"
+  ],
+  "type": "string"
+}

First observedJul 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description goes far beyond the annotations by disclosing concrete failure behavior (location_not_found, no nationwide fallback), unit semantics per search type, sales-only metric constraints, oracle.verified requirements, notarial source conditions, and sub-area rollup logic. No statements contradict annotation readOnly/idempotent/destructive hints.

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

Conciseness4/5

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

The description is longer than most, but every block earns its space because it covers caveats that would otherwise be unseen (error behaviours, oracle trust conditions, municipality rollup). It is front-loaded with purpose and usage, then stacks internal logic. It could be tightened slightly, but the density justifies most of the length.

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 tool that includes an output schema and has this many edge cases, the description gives almost everything the agent needs: output purpose, parameter effects, error shapes, data provenance, source verification, price-unit rules, and sub-area resolution. The presence of an output schema plus this level of behavioural detail makes the definition contextually complete.

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 67% and the schema already documents location and available property_type slugs. The description adds meaningful semantics where the schema is thin: search_type controls price units (total, per month, per week), prices are labelled, and median_price_per_sqm applies only to sales. Location behavior on unknown names is also clarified, though semantics for property_type could go a bit deeper.

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 opens with a specific verb and resource ('Return aggregate market context') and lists highly concrete outputs (active listings, median/mean price, median €/m², bedroom bands). It also names the filter dimensions, making the tool distinct from sibling listing/property tools like search_properties and get_property.

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 explicitly states when to use this tool: 'before recommending a price or commenting on whether a listing is good value.' It does not identify conflicting sibling tools by name, so an agent might still need to infer why not to use verified_valuation or search_properties, but the contextual trigger is clear.

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

All PropertyList: Spanish Property MLS 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?