PropertyList — Spanish Property MLS

verified_valuation

Read-onlyIdempotent

Get a valuation for a property or area from recorded market data, not asking prices. Returns the €/m² for the municipality and segment, an indicative valuation when you give a size (build_sqm) or a listing reference, and a content-hashed attestation URL the figure can be cited from.

Check verified before citing. It is true ONLY for Spanish figures drawn from the notarial register (Consejo General del Notariado) with at least 10 recorded transactions behind them. Elsewhere - Portugal and Cyprus especially - the figure comes from a national house-price index and is an estimate: transaction_backed is false, source_label names the real source, and it must not be described as notary-verified. indicative_band_pct widens as the evidence thins.

Only two segment attestations exist per municipality, so a request for penthouse or townhouse resolves to the nearest attested segment. property_type is the segment actually used and requested_property_type is what you asked for; when they differ the text says so. Also returns our proprietary network achieved-sale figure where available. If no attestation covers the area yet, it says so plainly (use area_market_summary for asking-price stats instead).

Input Schema

TableJSON Schema

Name	Required	Description
`build`	No	Alias of build_sqm.
`location`	No	Municipality / city name, e.g. "Marbella". Ignored if a reference is given.
`build_sqm`	No	Built size in m² to value. Optional.
`reference`	No	Value a specific PropertyList listing by reference (uses its municipality, type and size). Optional.
`build_size`	No	Alias of build_sqm.
`property_type`	No	Optional segment slug: apartment, villa, penthouse, townhouse, plot. Defaults to the municipality-wide figure.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`source`	No
`network`	No
`location`	Yes
`on_chain`	No
`verified`	Yes
`build_sqm`	No
`period_end`	No
`sample_size`	No
`content_hash`	No
`source_label`	No
`property_type`	No
`attestation_url`	No
`indicative_range`	No
`transaction_backed`	No
`valuation_estimate`	No
`indicative_band_pct`	No
`verified_price_per_sqm`	No
`requested_property_type`	No

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations (readOnly, idempotent), the description discloses the verification logic (verified field only true for Spanish notarial data), the content-hashed attestation URL, and the fallback respectively. It also notes the difference between property_type and requested_property_type, adding context not present in 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 well-structured: a clear purpose first, followed by key behavioral notes, and finally edge cases. All information is dense and relevant, with no redundancy or filler.

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?

Given the tool's complexity (6 parameters, output schema, regional variations, segment limitations), the description covers the essential operational context: verification handling, geographical differences, segment fallback, and an explicit alternative tool. It leaves no critical ambiguity for the agent.

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% and descriptions are clear, but the tool description adds value by explaining the interaction between property_type and requested_property_type, and how build_sqm influences the valuation type. This goes beyond the schema and justifies a score above the baseline.

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 clearly states it fetches a valuation from recorded market data (not asking prices), returning €/m² and an attestation URL. It distinguishes from siblings like area_market_summary by explicitly tailoring for market data insights.

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?

It provides explicit guidance on when to use this tool (for notary-verified Spanish data) versus area_market_summary for asking-price stats. It also cautions against citing Portugal/Cyprus figures as notary-verified and explains the segment fallback for penthouse/townhouse.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation4/5

Most tools have clear, distinct purposes. Some confusion possible between search_properties and find_properties_by_description, but descriptions clearly differentiate structured vs. free-form. Also area_market_summary vs verified_valuation both provide market data, but different types (asking vs notary). Overall well-differentiated.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: create_contact, create_listing, find_contacts, get_property, list_agencies, log_note, search_properties, etc. Names are predictive and actions are clear.

Tool Count4/5

14 tools is on the higher end of the ideal range (3-15) but appropriate for a property platform that covers both public MLS search and agency CRM functions. It could be split into two servers (public search vs. agency CRM) but still remains manageable.

Completeness4/5

Covers core flow well: location lookup, market context, search, property details, valuations, and agency CRM (contacts, listings, leads, notes). Minor gaps: no tool for updating a listing (create_listing only creates drafts), and no delete/update for contacts. But primary workflows are supported.

Resources

Need Help?