PropertyList: Spanish Property MLS

Submit enquiry

submit_enquiry

Submit an enquiry (lead) about a specific listing on behalf of a prospective buyer or tenant. Use this once the user has chosen a property and wants the agency to contact them. The listing agency receives the enquiry in their CRM and follows up directly.

This is the supported way to contact a listing agency - direct phone or email details are not exposed by other tools. Works without an API key up to a small daily allowance, counted per IP address, or per account for an app linked to a PropertyList account; an API key raises it to 40 enquiries per key in any 24 hours. Provide the property reference (from search results) plus the enquirer's contact details. Only submit with the person's clear intent and consent - this sends their details to a real estate agency.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Enquirer's full name.
`email`	Yes	Enquirer's email address.
`phone`	Yes	Enquirer's phone number (with country code where possible).
`message`	No	Optional message / what they want to know or arrange (e.g. a viewing).
`language`	No	Preferred language for the agency to reply in.	en
`reference`	Yes	PropertyList listing reference the enquiry is about, e.g. 'PLE-12345'.

Output Schema

TableJSON Schema

Name	Required	Description
`agency`	No	The agency that received the enquiry.
`status`	Yes
`lead_id`	Yes
`reference`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "agency": {
+      "description": "The agency that received the enquiry.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "lead_id": {
+      "type": "integer"
+    },
+    "reference": {
+      "type": "string"
+    },
+    "status": {
+      "enum": [
+        "submitted"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "lead_id",
+    "reference"
+  ],
+  "type": "object"
+}

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

First observedJul 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses rate limits (small daily allowance per IP/account; 40 per key per 24h), that the agency receives the lead in their CRM and follows up, and requires explicit user intent and consent. The annotations only cover mutation/openWorld/idempotency, so this added context is genuinely valuable.

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?

Front-loads purpose then flows into usage, transport details, limits, and consent. Most sentences carry useful information, though the rate-limit and consent material runs a little long for the core action.

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 mutation tool with an output schema available, the description covers purpose, timing, alternatives, consent prerequisites, and quota behavior. Nothing an agent needs to call it correctly is missing, and return values are delegated to the output schema.

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 description coverage is 100%, so the schema already documents all six parameters, establishing a baseline of 3. The description adds only marginal value by noting the reference comes 'from search results' and that both reference and contact details are required, without clarifying the optional message or language fields.

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 ('Submit an enquiry (lead) about a specific listing') plus the actor ('on behalf of a prospective buyer or tenant'). It explicitly distinguishes itself from sibling tools by noting it is the only supported contact path, so an agent can tell it apart without opening a 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?

Gives an explicit trigger ('once the user has chosen a property and wants the agency to contact them') and names the alternative scenario ('direct phone or email details are not exposed by other tools'). The consent precondition further constrains when it should and shouldn't be called.

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?