EPK Properties Public Knowledge MCP

Search public properties

search_properties

Read-onlyIdempotent

Use this when the user wants only public EPK Properties listings with explicit country, sale/rent, property type, price, bedroom, bathroom, area, location, or descriptive-keyword filters. SALE and RENT searches also include SALE_AND_RENT listings because they are available for the requested operation. If the same request also asks for guides or regulations, use search instead so both kinds appear together.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_properties"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`query`	No	Location, property name, address, or keywords matched against public listing text.
`offset`	No
`country`	No	PTY for Panama or DOM for the Dominican Republic.
`language`	No	Language for descriptions and canonical listing URLs.	es
`max_area`	No	Maximum area in square metres.
`min_area`	No	Minimum area in square metres.
`max_price`	No
`min_price`	No
`max_bedrooms`	No	Maximum bedrooms; set equal to min_bedrooms for an exact bedroom count.
`min_bedrooms`	No	Minimum number of bedrooms.
`max_bathrooms`	No	Maximum bathrooms; set equal to min_bathrooms for an exact bathroom count.
`min_bathrooms`	No	Minimum number of bathrooms.
`property_type`	No
`operation_type`	No	Search by availability: SALE includes SALE and SALE_AND_RENT listings; RENT includes RENT and SALE_AND_RENT listings.

Output Schema

Name	Required	Description	Default
`limit`	Yes
`total`	Yes
`offset`	Yes
`results`	Yes
`has_more`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedAug 31, 2026

changedInput schema / properties / operation_type / description

Previous value: -"Search properties for sale or rent."New value: +"Search by availability: SALE includes SALE and SALE_AND_RENT listings; RENT includes RENT and SALE_AND_RENT listings."

changedInput schema / properties / query / description

Previous value: -"Location, property name, address, or descriptive keywords."New value: +"Location, property name, address, or keywords matched against public listing text."

addedOutput schema / properties / results / items / properties / operation_type / description

Added value: +"Published availability; SALE_AND_RENT satisfies either a sale or rent search."

addedOutput schema / properties / results / items / properties / operation_type / enum
```
Added value: +[
+  "SALE",
+  "RENT",
+  "SALE_AND_RENT"
+]
```

Changed4 schema fields changedAug 4, 2026

addedInput schema / properties / max_bathrooms

Added value: +{
+  "description": "Maximum bathrooms; set equal to min_bathrooms for an exact bathroom count.",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / max_bedrooms

Added value: +{
+  "description": "Maximum bedrooms; set equal to min_bedrooms for an exact bedroom count.",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / min_bathrooms / description
```
Added value: +"Minimum number of bathrooms."
```
addedInput schema / properties / min_bedrooms / description
```
Added value: +"Minimum number of bedrooms."
```

First observedAug 4, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's job is to add context beyond that. It adds the public-only scope constraint (not present in the schema) and the non-obvious SALE_AND_RENT inclusion behavior. That behavior is partially redundant with the operation_type parameter description, but the description still adds genuine value over the 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?

Three sentences with the core purpose front-loaded; each sentence serves a distinct function: scoping the tool, disclosing inclusion behavior, and routing to the sibling. The SALE_AND_RENT sentence is slightly redundant with the operation_type schema description, which keeps this from a 5, but there is no wasted prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, annotations carry the safety profile, and the sibling set is large (five tools), the description covers the critical routing decisions (vs `search`), the scope boundary (public only), and a non-obvious result behavior. The main gap is that with 0 required parameters, the description never states what happens when no filters are supplied, and it doesn't clarify pagination behavior — minor gaps for a read-only, output-schema-backed search tool.

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 67%, below the high-coverage baseline, so the description should compensate. It names the filter dimensions (price, property type, area, bedrooms, bathrooms) which loosely maps to the undocumented params (min_price, max_price, property_type), providing some compensation. However, it doesn't add detailed semantics beyond what the schema's own parameter descriptions already state, and pagination params (limit, offset) are not mentioned anywhere.

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 opens with a specific action ('Use this when the user wants only public EPK Properties listings') naming both the verb and the exact resource scope, then enumerates the filter dimensions (country, sale/rent, property type, price, bedroom, bathroom, area, location, keywords). It differentiates from the sibling `search` tool directly in the final sentence, so an agent can distinguish them without opening either 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?

Provides an explicit when-to-use condition ('when the user wants only public EPK Properties listings with explicit... filters') and an explicit when-not-to-use with a named alternative ('If the same request also asks for guides or regulations, use search instead'). The SALE_AND_RENT inclusion note also prevents a class of incorrect calls where an agent assumes SALE returns only SALE listings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All EPK Properties Public Knowledge MCP 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?