Loading ToolBench
Unofficial MCP server for PropertyGuru Singapore & Malaysia property listings — searches Next.js SSR data (no auth, no API key)
Two tools with complete input schemas and descriptions, but significant gaps in output documentation and error handling. search_listings has a detailed description (194 chars) and comprehensive schema with 11 parameters, all typed and most described. get_listing_count is simpler but adequate. However, neither tool documents its return schema structure, LLMs cannot plan downstream operations without knowing what fields to expect. Error handling is minimal: fetch_next_data() raises RuntimeError with some context (Cloudflare 403, missing __NEXT_DATA__), but tools don't guide recovery. No parameter validation, no rate limiting, no idempotency guarantees. Naming is clear (verb_noun pattern). Security is reasonable (read-only operations, no secrets in params). Composition is sound, two focused tools with clear separation.
Cheap probe — returns the count PropertyGuru produced for a given search, without returning listing contents.
Search PropertyGuru SG / MY listings. Returns up to `limit` listings with the FULL 48-field listingData (price, psf, address, mrt, tenure, buildYear, photos, agent, etc). No server-side pruning — caller must budget context.
Output schemas not documented. LLMs cannot infer what fields search_listings returns (e.g., does listingData include all 48 fields? what are their types?). Agents cannot plan downstream operations or extract required data.
Error handling lacks recovery guidance. RuntimeError messages mention Cloudflare 403 and __NEXT_DATA__ parsing, but tools don't tell LLMs what to do next (retry? use different region? check PropertyGuru status?). Errors should categorize as retryable vs. fatal.
No pagination support. search_listings fetches one page (default 25, cap 40) but does not return total_count or next_cursor. Large result sets cannot be iterated; agents cannot know if more results exist.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Parameter descriptions incomplete. bedrooms_min/bedrooms_max lack explanation of how they interact (e.g., 'if both set and equal, treated as exact match'). sort enum values (price_asc, price_desc, date, psf) are not described. freetext description is vague ('Search text: area / condo / district / MRT'), should specify format and examples.
No input validation or constraint documentation. limit parameter caps at 40 but no min/max in schema. price_min/price_max unbounded, LLMs could pass negative or absurdly large values. bedrooms_min/bedrooms_max lack range constraints.