PropertyList: Spanish Property MLS

Search properties

search_properties

Read-onlyIdempotent

Search PropertyList's full Spanish property MLS by structured filters. Use for queries that translate cleanly to fields: bedrooms, bathrooms, price ceiling, property type, area name. For free-form briefs use find_properties_by_description instead.

Returns a paginated list with summary text plus structured JSON. Every property carries oracle_verified and oracle_attestation_url — true when PropertyList Oracle holds a verified attestation for the listing's municipality and segment.

A location we do not hold returns zero results with error: location_not_found and location_match.matched: false. It never substitutes listings from other areas.

location.city is whatever tier the listing was filed under and may be a municipality OR a locality inside one. To place a listing administratively use location.municipality (with its INE municipality_code); it is null, never guessed, when we cannot resolve it.

location.latitude / location.longitude are present only when we hold a real, publishable coordinate; the fields are absent otherwise, and are never 0,0. location.coordinates_precision says what the point is: exact or street is the property itself, locality or administrative_area is an area centroid (accurate to the town, not the building), unknown is a pin we hold no precision record for.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`page`	No
`language`	No	Preferred language for property titles and description excerpts.	en
`location`	No	Free-text place name (city, suburb, or urbanisation). e.g. 'Marbella', 'Nueva Andalucia', 'Sotogrande'. Pre-resolved with autocomplete_location if you need to confirm match.
`page_size`	No
`price_max`	No	Maximum price in euros (sale) or monthly euros (rent).
`price_min`	No	Minimum price in euros (sale) or monthly euros (rent).
`search_type`	No	Listing market. Defaults to 'for-sale'.
`bedrooms_max`	No
`bedrooms_min`	No
`bathrooms_min`	No
`property_types`	No	Comma-separated slugs: apartments, villas, penthouses, plots, townhouses, commercial.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`page`	Yes
`error`	No
`total`	Yes
`limits`	No
`page_size`	Yes
`properties`	Yes
`location_match`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 10, 2026
- addedOutput schema / properties / limits
```
Added value: +{
+  "type": [
+    "object",
+    "null"
+  ]
+}
```

Changed1 schema field changedAug 23, 2026

changedInput schema / properties / language / enum

Previous value: -[
-  "en",
-  "es",
-  "de",
-  "fr",
-  "it",
-  "nl",
-  "pt",
-  "bg",
-  "el",
-  "da",
-  "sv",
-  "no",
-  "fi"
-]New value: +[
+  "en",
+  "es",
+  "de",
+  "fr",
+  "it",
+  "nl",
+  "pt",
+  "bg",
+  "el",
+  "da",
+  "sv",
+  "no",
+  "fi",
+  "pl",
+  "ru"
+]

Changed2 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"
+  ]
+}

First observedJul 27, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already cover read-only and idempotency, and the description goes well beyond them by revealing exact failure behavior for unknown locations, the guarantee not to substitute listings, coordinate-omission rules, and the meaning of coordinates_precision. It adds rich context rather than 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.

Conciseness5/5

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

The description is front-loaded with purpose, then use guidance, then behavioral expectations. Every sentence earns its place: error semantics and coordinate precision are dense but directly relevant, with no filler or restatement of structured fields.

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 complex read-only search tool, the description covers the key behaviors an agent needs: pagination, location-not-found behavior, oracle verification, municipality resolution nuance, and coordinate precision. Since an output schema exists, return-shape details do not need to be repeated here.

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?

With 55% schema coverage, the description compensates by mapping filter categories to actual parameters and by explaining subtle location semantics such as city tier, municipality resolution, and coordinate presence. It does not restate every schema field, but it adds meaningful guidance beyond the bare schema, especially for location behavior.

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 states a specific verb and resource: 'Search PropertyList's full Spanish property MLS by structured filters.' It also distinguishes itself from find_properties_by_description by explicitly naming the sibling for free-form queries, so an agent can select correctly 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.

Usage Guidelines5/5

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

The description gives clear when-to-use guidance: structured filters such as bedrooms, bathrooms, price, type, and area; and an explicit when-not-to-use with the alternative: 'For free-form briefs use find_properties_by_description instead.' This is direct and actionable.

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?