Tu Lugar

Search Listings

search_listings

Read-only

Search real estate listings. Filter by city, price, bedrooms, property type, or a specific agency/company. Returns TuLugar listings first, then "En otros sitios": homes on agency websites (RE/MAX, Century 21, Rent-A-House) in the same place, shown on the same map.

Input Schema

Name	Required	Description
`city`	No	City name only, e.g. "Asunción" — never with the country in it
`sort`	No
`limit`	No	Max 20
`company`	No	Agency/company NAME to list only their properties, e.g. "RE/MAX Urbana" (resolved automatically; punctuation/accents ignored).
`country`	No	Country name whenever the user gives it or it is clear, e.g. "Costa Rica" for "San José Costa Rica", "Argentina" for "Córdoba, Argentina".
`bedrooms`	No
`building`	No	Building/tower NAME to list the actual units for sale/rent in it, e.g. "Petra Tower" (punctuation/accents ignored). Use this — not search_projects — when the user wants the real listings in a named building.
`map_zoom`	No	Zoom of the interactive map this search opens/moves (5 country · 11 metro area · 13 city · 15 barrio · 17 streets). Omit normally; set it only when the user asks to zoom in/out or for a wider/closer view — start from the zoom in the page they are on and step ±2.
`amenities`	No	Comma-separated amenities/features the property must have, in the user's own words and language, e.g. "piscina, cochera" or "pool, gym". Common ones: pool/piscina, gym/gimnasio, garden/jardín, balcony/balcón, terrace/terraza, parking/cochera, furnished/amoblado, airConditioning/aire, security/seguridad, elevator/ascensor, bbq/parrilla/quincho, laundry/lavadero. Multiple = must have all.
`max_price`	No
`min_price`	No
`listing_type`	No
`neighborhood`	No
`property_type`	No	apartment, house, land, commercial
`price_currency`	No	Currency of min_price/max_price: USD (default), PYG, ARS, BRL, MXN … — e.g. PYG for "hasta Gs. 3.000.000".

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

addedInput schema / properties / map_zoom

Added value: +{
+  "description": "Zoom of the interactive map this search opens/moves (5 country · 11 metro area · 13 city · 15 barrio · 17 streets). Omit normally; set it only when the user asks to zoom in/out or for a wider/closer view — start from the zoom in the page they are on and step ±2.",
+  "type": "number"
+}

Changed3 schema fields changedOct 19, 2026

changedInput schema / properties / city / description

Previous value: -"City name, e.g. \"Asunción\""New value: +"City name only, e.g. \"Asunción\" — never with the country in it"

addedInput schema / properties / country

Added value: +{
+  "description": "Country name whenever the user gives it or it is clear, e.g. \"Costa Rica\" for \"San José Costa Rica\", \"Argentina\" for \"Córdoba, Argentina\".",
+  "type": "string"
+}

addedInput schema / properties / price_currency

Added value: +{
+  "description": "Currency of min_price/max_price: USD (default), PYG, ARS, BRL, MXN … — e.g. PYG for \"hasta Gs. 3.000.000\".",
+  "type": "string"
+}

First observedJul 13, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely useful behavioral context beyond the annotations: results are TuLugar listings first, then "En otros sitios" aggregated agency-site homes from RE/MAX, Century 21, Rent-A-House, all shown on the same map. It doesn't cover pagination or limits, but the return-composition disclosure is substantive.

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?

Two sentences, tightly packed, with the core purpose front-loaded and the result-composition detail following. No filler sentences, though the quoted Spanish label and agency list make the second sentence slightly dense.

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

Completeness3/5

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

For a 15-parameter tool with no output schema, the description is adequate on overall behavior and return ordering but thin on parameter-level guidance and silent on sorting, limiting, and result-count behavior. An agent can call it, but several parameters remain ambiguous.

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 60%, so several parameters (bedrooms, min_price, max_price, neighborhood, sort) have no schema description. The description names some filters that map to those parameters but adds no syntax, units, or default semantics beyond the parameter names, so it only partially compensates for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Search real estate listings") and enumerates the filterable dimensions (city, price, bedrooms, property type, agency/company), so an agent knows broadly what it retrieves. It doesn't distinguish itself from nearby siblings like search, get_listing, or search_projects beyond the implicit mention of search_projects inside the building parameter description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (searching listings by filters) but gives no explicit when-to-use/when-not context and no named alternatives among siblings. An agent must infer that get_listing is for a known single property or that search_projects is for developments rather than listings.

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

All Tu Lugar 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?