Bangkok condos for rent and sale: search by budget, BTS/MRT station and walk time; median rents.
Scored across 5 tools
search_condos and nearby_condos both return condos, and area_stats and list_stations both surface station-level rent statistics, so some overlap exists. The descriptions clarify the spatial/filter vs directory/aggregate distinctions, but an agent may still hesitate between nearby search and station-filtered search.
All tool names use snake_case and are readable. The set mixes verb-led names (get_listing, list_stations, search_condos) with noun/adjective-led names (area_stats, nearby_condos), which is a minor inconsistency rather than a confusing one.
Five read-only tools cover search, listing detail, nearby lookup, station directory, and area statistics without bloat. The count is well matched to a focused Bangkok condo-search server.
Core search and stats workflows are covered: find listings, inspect a listing, explore nearby, list stations, and benchmark area prices. Minor gaps include no structured amenity or pet filters in search and no explicit browse-all/pagination mode, but agents can work around these via listing details and area tools.
Median rent or sale price and number of listings for one BTS/MRT station (within 1 km), one line, or one district or neighbourhood of Bangkok, overall and by bedrooms. Use it to tell whether a price is fair. Returns the bkkradar.com page.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the titles and links: en, fr, th, ja (Japanese) or zh (simplified Chinese). Use the user's language. | en |
| line | No | Line code or name ("BTS-SUK", "BTS Sukhumvit", "MRT Blue"), or a whole network: "BTS", "MRT". | |
| type | No | rent (monthly price) or sale (total price). | rent |
| station | No | BTS/MRT station name or code, e.g. "Asok", "Phrom Phong", "BTS-CEN". | |
| bedrooms | No | Also give the median for this number of bedrooms; 0 = studio, 3 or more = the 3+ group. | |
| district | No | District (khet) or neighbourhood: "Watthana", "Sathorn", "Thonglor", "Ari". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the description's main added value is scope: station results within 1 km, area-level aggregation, and bedroom breakdown. It also notes that it returns the bkkradar.com page, though the return format remains somewhat vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and front-loads the resource and scope. The final sentence about returning the bkkradar.com page is useful but slightly underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations and fully described schema, the description covers the core purpose, scope, and output content well enough to call the tool. It could do more to explain the returned page or how area selectors interact, especially since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds useful meaning by framing station, line, and district/neighbourhood as alternative area selectors and noting the 1 km station radius. It does not clarify whether multiple area selectors are mutually exclusive or how defaults are applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and scope: median rent/sale price and listing count for a Bangkok station/line/district, overall and by bedrooms. It is clear enough to distinguish from listing search tools, but it does not explicitly name or contrast with its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear use case: 'Use it to tell whether a price is fair.' However, it does not explain when to prefer it over search_condos or get_listing, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Details of one listing found by search_condos or nearby_condos: price, size, bedrooms, furnishing, pets, deposit, minimum lease, amenities, station and walk, and a warning when the post asks for money before a viewing. Returns its bkkradar.com link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Listing id, from search_condos or nearby_condos. | |
| lang | No | Language of the titles and links: en, fr, th, ja (Japanese) or zh (simplified Chinese). Use the user's language. | en |
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 that: it discloses the return payload shape (including a fraud warning when a post asks for money before a viewing) and that a bkkradar.com link is returned, which the agent could not infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the provenance ('found by search_condos or nearby_condos') comes first and the payload detail follows. The field enumeration is long but each item tells the agent what data is available, so it mostly earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of describing the return payload, and annotations cover the safety profile, so an agent can call this confidently. Minor gaps remain: no note on what happens when the id is unknown or expired, and no unit/currency note for price.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both the uuid id and the lang enum fully documented inline, so the description carries no burden here. It only hints that a link is returned, without noting that lang affects titles and links, so it adds no meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Details of one listing') and immediately ties it to the sibling tools that produce the id (search_condos, nearby_condos). The enumerated field list (price, size, bedrooms, furnishing, pets, deposit, minimum lease, amenities, station/walk, scam warning, link) makes it unmistakable versus the search siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'found by search_condos or nearby_condos' routes the agent clearly: call this after a search to expand a single result. It does not state explicit exclusions (e.g. 'do not use to browse many listings') or error behavior for a stale id, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bangkok's BTS, MRT and Airport Link stations with the number of rentals within 1 km and the median monthly rent by bedrooms (studio, 1, 2, 3+), busiest first, optionally for one line. Each station has its bkkradar.com page.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the titles and links: en, fr, th, ja (Japanese) or zh (simplified Chinese). Use the user's language. | en |
| line | No | Line code or name ("BTS-SUK", "BTS Sukhumvit", "MRT Blue"), or a whole network: "BTS", "MRT". | |
| limit | No | Stations to return, the busiest first: 40 by default, 200 at most. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld=false; the description adds valuable behavioral detail: it returns rental counts within 1 km, median rent split by bedrooms, sorts busiest first, and includes bkkradar.com page links. It does not discuss rate limits or response shape beyond those content hints, but for an annotated read-only list this is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the station/rent resource and no filler. Sorting, filtering, output metrics, and links each earn inclusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must carry return-value context; it identifies the key returned metrics and page links, making the tool callable without additional docs. Currency (e.g., THB) and exact response structure are not specified, leaving a minor completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so lang, line, and limit are already fully documented; the baseline is 3. The description only echoes the line filter and busiest-first ordering, adding little parameter-specific semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource precisely (Bangkok BTS/MRT/Airport Link stations), the metrics returned (rentals within 1 km, median rent by bedroom count), ordering (busiest first), and an optional line filter. It does not explicitly route against sibling tools such as area_stats or nearby_condos, so it is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the tool is for station-level rent data and notes the optional line filter, but gives no explicit when-to-use guidance, prerequisites, or exclusions versus area_stats, nearby_condos, or search_condos. The usage is inferable from the resource description but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Condos around a point in Bangkok, such as an office, a school, a residence or a station, given as lat/lng or as a place name or address. Same filters as search_condos plus radius_km, sorted by distance or by walk to a station. Returns bkkradar.com links.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the point (Bangkok area). | |
| lng | No | Longitude of the point (Bangkok area). | |
| lang | No | Language of the titles and links: en, fr, th, ja (Japanese) or zh (simplified Chinese). Use the user's language. | en |
| sort | No | distance (closest to the point first) or station_walk (closest to a station first). | distance |
| type | No | rent (monthly price) or sale (total price). | rent |
| limit | No | Listings to return, 20 by default, 50 at most. | |
| place | No | Address or place in Bangkok instead of lat/lng: an office, a school, a station, a residence. | |
| bedrooms | No | Exact number of bedrooms; 0 = studio. | |
| max_price | No | Maximum price in THB (per month for rent). | |
| min_price | No | Minimum price in THB. | |
| radius_km | No | Distance from the point, at most, in km (straight line). | |
| min_bedrooms | No | At least this many bedrooms. | |
| min_size_sqm | No | Living area, at least, in m². | |
| property_kind | No | Kind of property; any for all. | condo |
| max_lease_months | No | 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. | |
| max_walk_minutes | No | Walk 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds valuable behavioral context: that sorting is either by distance or walk to a station, and that results are bkkradar.com links. It doesn't detail pagination or result shape, but that's secondary for a read-only tool with annotated safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The core purpose and input modes are front-loaded, followed by the differentiating filter and return-format detail in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter proximity-search tool with full schema coverage and clear annotations, the description covers the essential: input modes, filter relationship to search_condos, sorting, and return format (links). It lacks detail on result structure or pagination, but with no output schema and a low-risk read operation, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all 16 parameters—including radius_km and sort—are well documented in the schema. The description reiterates the radius and sort concepts but adds no additional semantics or format details beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb-and-resource ('Condos around a point in Bangkok') with scope (lat/lng or place name/address) and explicitly distinguishes itself from its sibling by noting it applies the 'same filters as search_condos plus radius_km'. An agent can tell exactly what it returns and how it differs from search_condos 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly establishes the use case—proximity search around a point—and names search_condos as the filter baseline, which implies the alternative for non-geo searches. No explicit when-not or exclusion is stated, but the context is unambiguous for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the titles and links: en, fr, th, ja (Japanese) or zh (simplified Chinese). Use the user's language. | en |
| line | No | Line code or name ("BTS-SUK", "BTS Sukhumvit", "MRT Blue"), or a whole network: "BTS", "MRT". | |
| sort | No | recent (newest first), price (cheapest first) or walk (closest to the station first). | recent |
| type | No | rent (monthly price) or sale (total price). | rent |
| limit | No | Listings to return, 20 by default, 50 at most. | |
| station | No | BTS/MRT station name or code, e.g. "Asok", "Phrom Phong", "BTS-CEN". | |
| bedrooms | No | Exact number of bedrooms; 0 = studio. | |
| district | No | District (khet) or neighbourhood: "Watthana", "Sathorn", "Thonglor", "Ari". | |
| max_price | No | Maximum price in THB (per month for rent). | |
| min_price | No | Minimum price in THB. | |
| min_bedrooms | No | At least this many bedrooms. | |
| min_size_sqm | No | Living area, at least, in m². | |
| property_kind | No | Kind of property; any for all. | condo |
| max_lease_months | No | 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. | |
| max_walk_minutes | No | Walk 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). |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
nearby_condos1 field changedInput schema / properties / max_lease_monthsAdded 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"
+}search_condos1 field changedInput schema / properties / max_lease_monthsAdded 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"
+}area_stats2 fields changedInput schema / properties / lang / descriptionPrevious 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."Input schema / properties / lang / enumPrevious value: -[
- "en",
- "fr",
- "th"
-]New value: +[
+ "en",
+ "fr",
+ "th",
+ "ja",
+ "zh"
+]get_listing2 fields changedInput schema / properties / lang / descriptionPrevious 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."Input schema / properties / lang / enumPrevious value: -[
- "en",
- "fr",
- "th"
-]New value: +[
+ "en",
+ "fr",
+ "th",
+ "ja",
+ "zh"
+]list_stations2 fields changedInput schema / properties / lang / descriptionPrevious 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."Input schema / properties / lang / enumPrevious value: -[
- "en",
- "fr",
- "th"
-]New value: +[
+ "en",
+ "fr",
+ "th",
+ "ja",
+ "zh"
+]nearby_condos2 fields changedInput schema / properties / lang / descriptionPrevious 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."Input schema / properties / lang / enumPrevious value: -[
- "en",
- "fr",
- "th"
-]New value: +[
+ "en",
+ "fr",
+ "th",
+ "ja",
+ "zh"
+]search_condos2 fields changedInput schema / properties / lang / descriptionPrevious 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."Input schema / properties / lang / enumPrevious value: -[
- "en",
- "fr",
- "th"
-]New value: +[
+ "en",
+ "fr",
+ "th",
+ "ja",
+ "zh"
+]area_statsget_listinglist_stationsnearby_condossearch_condosEvery long-term rental in Da Nang, Vietnam: search, buildings, median rents. No key, no account.
Search live published Thailand properties and projects from ThaiProps.
Search curated Bangkok, Thailand tours, activities, hotels, restaurants, nightlife and services.
Find NYC rental apartments by budget, neighborhood, commute and amenities, with deal scores.
Add one secure layer between your agents and this server.
