PropertyList: Spanish Property MLS

Get enquiry consent text

get_enquiry_consent

Read-onlyIdempotent

Get the consent text to show a person before their enquiry (submit_enquiry) or viewing request (request_viewing) about a listing is sent. It names the agency selling or letting the listing and PropertyList, and says what is passed on. Show consent_text to the person, in full, and ask whether they agree. Only when they clearly say yes, call submit_enquiry or request_viewing with consent: true. Nothing is sent or stored by this tool.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "reference": "<reference>"
    },
    "name": "get_enquiry_consent"
  }
}

Input Schema

Name	Required	Description	Default
`language`	No	The language the person writes in. The text comes in it where PropertyList speaks it, else in English.	en
`reference`	Yes	PropertyList listing reference, e.g. 'PLE-12345'.

Output Schema

Name	Required	Description
`agency`	No	The agency the enquiry would go to.
`language`	Yes
`reference`	Yes
`consent_text`	Yes	Show this to the person and ask whether they agree.
`consent_version`	Yes
`shared_with_agency`	No	What the agency receives.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, and the description reinforces this with 'Nothing is sent or stored by this tool', which matters because the tool sits in front of two write actions. It additionally discloses what the consent text contains (agency name, PropertyList, what is passed on). It stops short of covering availability or failure modes, so a 4 rather than 5.

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 in the first sentence, followed by what the text contains and then the workflow gate, which is a logical order. The sentences all carry functional content, though the closing 'Nothing is sent or stored' restates the readOnly annotation and could be folded into the first sentence.

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 covers the remaining gaps an agent would face: what the text contains, how to present it, and the exact condition for the follow-up write call. Nothing needed to invoke and act on this 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 coverage is 100%, so both the listing reference format and the language enum with its English-fallback behaviour are already documented in the schema. The description only implies the listing reference ('about a listing') and says nothing about the language parameter, so it adds little beyond structured data — baseline 3.

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 — 'Get the consent text' — and scopes it precisely with 'to show a person before their enquiry (submit_enquiry) or viewing request (request_viewing) about a listing is sent'. It names the two sibling tools it gates, so an agent can distinguish it from them without opening any 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 explicit when-to-use ('before their enquiry or viewing request ... is sent') and when-to-proceed ('Only when they clearly say yes, call submit_enquiry or request_viewing with consent: true'). It also prescribes the handling of the result — show in full and ask — leaving nothing to inference.

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?