Skip to main content
Glama
Sign In

Singapore new launches

by ai.bluebed.property
OverviewDiscussionsAdmin

search_floor_plans

Searches floor plans across the reviewed launches, a selection during the trial. Filter by property type (condo or ec), bedrooms, size in square feet, postal district, launch stage, features such as a kitchen window, and a maximum budget in Singapore dollars. Plans in matches meet every constraint you supplied; plans in close miss exactly one, or could not be checked on one, as shown in each plan's fit (met, missed or unknown). The close list holds at most 20 plans, those with the fewest unknowns first; close_total says how many came close and close_truncated whether some were left out, so narrow the filters to see them. Cull both lists against what your user actually wants. Each result gives the plan, its stacks (stacks_note explains an asterisk), a link to the plan image, and a price with its kind and date. When nothing matches or comes close, the reply names which filters excluded the plans. Prices are guidance from developer price lists: indicative before launch, reset on booking day, and subject to promotions afterwards. Treat them as a starting point and confirm with the agent. Every answer carries its source, the date it was reviewed, the stage of the launch, and the agent's licence details. Anything the developer material does not settle is returned as a gap with the question to ask, never as a guess.

Input Schema

NameRequiredDescriptionDefault
tagsNoFeature ids, for example kitchen_window
stagesNopre-marketing, preview, launch or after-launch
bedroomsNoWhole number of bedrooms, 1 to 6
max_sqftNoMaximum size in square feet
min_sqftNoMinimum size in square feet
districtsNoPostal districts, 1 to 28
budget_maxNoMaximum price in Singapore dollars
property_typesNocondo or ec. Leave out to include both.
include_sold_outNoInclude sold-out launches. Not scored as a constraint.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / property_types
      Added value: +{
+  "description": "condo or ec. Leave out to include both.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it defines the matches/close/fit semantics (met, missed, unknown), the 20-cap and unknown-first ordering of close, close_total/close_truncated, the no-result behavior of naming excluding filters, and price validity caveats before/at/after launch. It also states provenance (source, review date, stage, agent licence) and that unresolved items come back as gaps rather than guesses.

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?

Front-loads purpose and filters, then moves to result semantics and price caveats in a logical order. It is dense and long for a search tool, and the advisory sentence 'Cull both lists against what your user actually wants' is instruction rather than description, but little is genuinely redundant.

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

Completeness5/5

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

For a 9-parameter, zero-required search tool with no output schema and no annotations, it covers matching rules, truncation, empty results, result payload shape, price reliability and provenance — every behavior an agent needs to call and interpret it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3; the description adds real meaning by listing example feature ids (kitchen_window), property types (condo or ec), launch stages, and the SGD currency of budget_max. It also clarifies that filters are conjunctive, which is semantics the schema cannot express.

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?

Opens with a specific verb+resource ('Searches floor plans') plus scope ('across the reviewed launches, a selection during the trial'), then enumerates the filterable dimensions. An agent can tell this apart from list_launches, get_launch or get_unit_type without opening any schema.

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

Usage Guidelines4/5

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

Gives clear operational context: plans in 'matches' satisfy every constraint, plans in 'close' miss exactly one, and the instruction to narrow filters when close_truncated is set. It never explicitly names a sibling alternative (e.g. get_unit_type for a single plan's detail), so the routing is implied rather than stated.

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

All Singapore new launches toolsInspect
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