Skip to main content
Glama

PropertyList: Spanish Property MLS

Get property details

get_property
Read-onlyIdempotent

Fetch the full record for one PropertyList listing by its reference code (the human-readable id like 'PLE-12345'). Use this once the user has settled on a listing from search_properties or find_properties_by_description and wants details or photos. To contact the listing agency, use submit_enquiry - direct phone or email details are not part of the payload.

Works without an API key up to a daily allowance of listings, counted per IP address, or per account for an app linked to a PropertyList account; an API key raises that allowance. The free allowance is for an assistant answering a person's questions: reading listings in bulk, or showing them on a website, needs MCP Pro or the agency's website feed. When the day's allowance is used the result carries error and limits instead of property.

photos holds the listing's first photos on the free tier and all of them with MCP Pro; photos_total says how many the listing has.

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.

Commercial premises (commercial true) carry no bedrooms: read commercial_facts (usable area, licence, price per m², a letting's terms, a traspaso's rent and years left) and tenure (freehold, or traspaso for a sale of the lease and the business).

location.latitude / location.longitude are present whenever we hold a real 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, approximate is a pin the agent keeps private, rounded to about 1 km, 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
NameRequiredDescriptionDefault
languageNoen
referenceYesPropertyList reference, e.g. 'PLE-12345'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
limitsNo
propertyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / property / properties / commercial
      Added value: +{
      +  "description": "Commercial premises rather than a home.",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / property / properties / commercial_facts
      Added value: +{
      +  "description": "Commercial premises only: the facts a buyer or tenant of premises reads first, only those the listing has.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / property / properties / tenure
      Added value: +{
      +  "description": "How a commercial sale is sold: freehold, or traspaso (the lease and the business taken over). null for homes and lettings.",
      +  "enum": [
      +    "freehold",
      +    "traspaso",
      +    null
      +  ],
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  2. Changed4 schema fields changed
    • addedOutput schema / properties / error
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / limits
      Added value: +{
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / property / properties / photos_total
      Added value: +{
      +  "description": "How many photos the listing has. `photos` holds the first few on the free tier, all of them with MCP Pro.",
      +  "type": "integer"
      +}
    • removedOutput schema / required
      Removed value: -[
      -  "property"
      -]
  3. Changed2 schema fields changed
    • 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"
      +]
    • addedOutput schema / properties / property / properties / features_language
      Added value: +{
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With annotations already declaring read-only, idempotent, non-destructive, and closed-world behavior, the description adds substantial operational context beyond them. It discloses daily allowance rules, per-IP versus per-account counting, the error-and-limits response when exhausted, photo-tier behavior, and nuanced location/coordinate precision semantics. It also explains commercial-premises return fields and that direct phone/email details are not part of the payload.

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 long but front-loads the core purpose and then organizes secondary details into paragraphs. Most content earns its place because it clarifies tiered access and return-field semantics beyond the output schema. It could be tightened slightly, but the length is justified by the tool's allowance, photo, location, and commercial nuances.

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 output schema exists, the description does not need to enumerate every return field, yet it supplies critical context for interpreting errors, limits, photo coverage, location.city versus location.municipality, coordinate precision, and commercial premises. It pairs well with the annotations and leaves no significant gap for correct invocation or interpretation.

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

Parameters3/5

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

Schema coverage is 50%: reference is documented in the schema, while language has an enum but no description. The description repeats the reference-code format (e.g., 'PLE-12345') and does not explain the language parameter or its default. With the schema already covering the required parameter and no added semantics for the optional one, this meets the baseline for partial coverage.

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: fetch the full record for one PropertyList listing by reference code. It differentiates itself from search_properties and find_properties_by_description by describing the settled-listing use case, and it routes agency-contact needs to submit_enquiry. An agent can identify the tool without opening the schema.

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 gives explicit timing and alternatives: use this once the user has settled on a listing from search_properties or find_properties_by_description and wants details/photos, and use submit_enquiry for agency contact. It also states when the free allowance allows use versus when MCP Pro or an agency feed is required. This covers when to use, when not to use, and which sibling to use instead.

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.

Resources