Skip to main content
Glama
Sign In

Singapore new launches

by ai.bluebed.property
OverviewDiscussionsAdmin

rules_for_buyer

Quotes the Singapore property rules that apply to a buyer, exactly as published, with the authority, source link, effective date and the date each was last checked: additional buyer's stamp duty, buyer's stamp duty, financing limits and seller's stamp duty. It quotes and does not work out any duty or rate; read the figure from the quote. Seller's stamp duty depends on the purchase date, so supply purchase_date to get the right regime. Supply slug for an executive condominium launch to add the EC rules that apply to its site. A rule that is being re-checked is named without its quote. This is general information and not advice on a particular purchase; confirm with the agent.

Input Schema

NameRequiredDescriptionDefault
slugNoA launch slug. For an executive condominium, the reply adds the EC rules for that site.
profileYesThe buyer's status: sc (Singapore Citizen), spr (Singapore Permanent Resident), foreigner or entity
purchase_dateNoDate the property was or will be bought, as YYYY-MM-DD. Chooses the seller's stamp duty regime.
properties_ownedYesResidential properties the buyer already owns: 0, 1 or 2 (2 means two or more)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / slug
      Added value: +{
+  "description": "A launch slug. For an executive condominium, the reply adds the EC rules for that site.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses what each quote carries (authority, source link, effective date, last-checked date) and a genuine edge case, that a rule being re-checked is returned by name without its quote. It omits any statement about behavior on invalid profile or slug values, which is the only meaningful gap for an otherwise side-effect-free read tool.

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-loaded with the core action, then layered with constraints and the disclaimer; essentially every sentence carries information. It is a dense single block rather than scannable bullets, but nothing is padding.

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?

For a four-parameter tool with no output schema and no annotations, the description covers return contents, the non-computation contract, an edge case, and a disclaimer. Only validation/error behavior and output shape nuances remain unspecified, which is minor given the verb 'quotes' sets expectations.

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 100%, so every parameter is already documented, including that purchase_date selects the seller's stamp duty regime and that slug adds EC rules. The description restates those links rather than adding syntax, allowed values, or format details beyond the schema, so the baseline of 3 applies.

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?

The description opens with a specific verb and resource: it "quotes the Singapore property rules that apply to a buyer, exactly as published", then enumerates the four rule families covered (ABSD, BSD, financing limits, SSD). No sibling tool (launches, areas, bookings) could be mistaken for this one.

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?

It gives conditional guidance for optional inputs: supply purchase_date to get the right seller's stamp duty regime, supply slug for an EC launch to add site rules. It also sets a firm usage boundary by saying it quotes and does not compute rates, so the agent knows to read the figure from the quote rather than expect a calculation. It stops short of naming an alternative source for computed duties.

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