PropertyList: Spanish Property MLS

Submit enquiry

submit_enquiry

Destructive

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 name and email. A phone number is optional: pass it only when the person gives it and wants to be called; email alone is enough. Only submit with the person's clear intent and consent - this sends their details to a real estate agency, and an enquiry cannot be recalled.

Input Schema

Name	Required	Description	Default
`name`	Yes	Enquirer's full name.
`email`	Yes	Enquirer's email address.
`phone`	No	Optional. The enquirer's phone number (with country code where possible), only if they give it and want a call. Email alone is enough.
`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

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.

Changed2 schema fields changedOct 30, 2026

changedInput schema / properties / phone / description

Previous value: -"Enquirer's phone number (with country code where possible)."New value: +"Optional. The enquirer's phone number (with country code where possible), only if they give it and want a call. Email alone is enough."

changedInput schema / required

Previous value: -[
-  "reference",
-  "name",
-  "email",
-  "phone"
-]New value: +[
+  "reference",
+  "name",
+  "email"
+]

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?

Beyond annotations (destructiveHint=true, openWorldHint=true, idempotentHint=false) it reveals what technically happens downstream (enquiry lands in the agency's CRM, agency follows up), the rate-limit model for anonymous vs account vs API-key callers, and that the action cannot be recalled. This is substantive context an agent could not derive from annotations alone.

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?

Purpose is front-loaded and the paragraphs each cover a distinct concern (what, when, limits, params, consent). It is slightly longer than needed, with the phone-number guidance repeated from the schema, which keeps it from a 5.

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?

With an output schema present, return values need no explanation, and the description fills the remaining gaps: consent, irreversibility, rate limits, API-key behavior, and which parameter values to supply. Nothing an agent needs to call this destructive tool correctly is missing.

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, and the description largely restates the phone/email guidance. It adds only marginal value, such as noting the `reference` comes from search results and the message can mention a viewing, which is why it sits at the baseline rather than above it.

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 first sentence states a specific verb (submit), a specific resource (enquiry/lead), and the exact object it concerns ('about a specific listing on behalf of a prospective buyer or tenant'). This lets an agent distinguish it from siblings like create_contact or schedule_viewing 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?

It explicitly states the trigger condition ('once the user has chosen a property and wants the agency to contact them') and rules out alternatives by noting that direct phone or email details are not exposed by other tools. The consent/irreversibility note functions as an additional when-to-use guard.

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?