Skip to main content
Glama

Search condos in Bangkok

search_condos
Read-onlyIdempotent

Search condos for rent or sale in Bangkok by budget (THB), bedrooms, BTS/MRT station or line, walking minutes to the station, district and size. Returns the matching listings with their bkkradar.com links and the same search on the map. Show the links to the user.

Input Schema

NameRequiredDescriptionDefault
langNoLanguage of the titles and links: en, fr, th, ja (Japanese) or zh (simplified Chinese). Use the user's language.en
lineNoLine code or name ("BTS-SUK", "BTS Sukhumvit", "MRT Blue"), or a whole network: "BTS", "MRT".
sortNorecent (newest first), price (cheapest first) or walk (closest to the station first).recent
typeNorent (monthly price) or sale (total price).rent
limitNoListings to return, 20 by default, 50 at most.
stationNoBTS/MRT station name or code, e.g. "Asok", "Phrom Phong", "BTS-CEN".
bedroomsNoExact number of bedrooms; 0 = studio.
districtNoDistrict (khet) or neighbourhood: "Watthana", "Sathorn", "Thonglor", "Ari".
max_priceNoMaximum price in THB (per month for rent).
min_priceNoMinimum price in THB.
min_bedroomsNoAt least this many bedrooms.
min_size_sqmNoLiving area, at least, in m².
property_kindNoKind of property; any for all.condo
max_lease_monthsNoRentals that accept a lease this short, at most, in months (1 to 6): 6 for a DTV stay of 180 days. Prices are then that lease's monthly rent when the post gives it, often higher.
max_walk_minutesNoWalk to the listing's nearest BTS/MRT station, at most, in minutes (straight line at 80 m a minute). With a station or line and no value: 12 (1 km).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / max_lease_months
      Added value: +{
      +  "description": "Rentals that accept a lease this short, at most, in months (1 to 6): 6 for a DTV stay of 180 days. Prices are then that lease's monthly rent when the post gives it, often higher.",
      +  "maximum": 6,
      +  "minimum": 1,
      +  "type": "integer"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / lang / description
      Previous value: -"Language of the titles and links: en, fr or th. Use the user's language."New value: +"Language of the titles and links: en, fr, th, ja (Japanese) or zh (simplified Chinese). Use the user's language."
    • changedInput schema / properties / lang / enum
      Previous value: -[
      -  "en",
      -  "fr",
      -  "th"
      -]New value: +[
      +  "en",
      +  "fr",
      +  "th",
      +  "ja",
      +  "zh"
      +]
  3. First observed

TDQS

A3.8/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 closed-world, so safety is covered. The description adds real value beyond them by disclosing the return payload: matching listings with bkkradar.com links plus the same search on the map, and an instruction to surface those links. Return shape, not filters, is the gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus a one-clause imperative. The filter dimensions are front-loaded, the return content follows, and the presentation instruction is last. No sentence is wasted.

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?

With 15 optional parameters, no output schema and no required fields, the description adequately covers what is searched and what comes back (links plus map). It omits what happens with zero filters and says nothing about result volume or paging beyond the schema's limit, a small residual gap for a listing 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 100%, so every one of the 15 parameters is documented in the schema, including the non-obvious max_lease_months and max_walk_minutes defaults. The description only restates the filter categories (budget in THB, bedrooms, station/line, walk minutes, district, size) without adding syntax or edge-case meaning, so baseline 3 applies.

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 and resource (search condos for rent or sale in Bangkok) and enumerates the filter dimensions: budget, bedrooms, BTS/MRT station or line, walking minutes, district, size. An agent immediately knows the tool's job. It does not name or differentiate itself from the closest sibling, nearby_condos, leaving the scope distinction implicit.

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?

"Show the links to the user" is an explicit output-handling instruction, which is useful. However there is no guidance on when to prefer this over nearby_condos or list_stations, and no exclusions or prerequisites. Usage is implied by the filter list rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources