Propely Singapore Property

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety and determinism are covered by structured data. The description adds a summary of the informational payload it returns, which is useful context, but says nothing about output format, sourcing, or whether the content is static. No contradiction with annotations.

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, front-loaded with what the tool is and followed immediately by the invocation condition. Every clause carries information; nothing is padded or repeated from the title.

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 zero-parameter, read-only informational tool with no output schema, the description covers what an agent needs: what it returns and when to call it. The only minor gap is that it doesn't characterize the response (static blurb vs. dynamic content), which an agent might want to know before relaying it.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond confirming this is a no-input informational call, which it implicitly does.

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 ('Explains') and resource ('what Propely is') and then enumerates the concrete content: Singapore owner-direct condo marketplace, Singpass-verified owners, no agents, 0% commission, free calculators. This is unmistakably distinct from the sibling calculator tools, which all compute numeric outputs.

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?

Gives an explicit trigger: 'Call this when the user asks about Propely, or wants to sell or buy a Singapore condo without an agent.' That is clear context for invocation. It stops short of a 5 because it names no exclusions or alternatives (e.g., 'do not use this for loan math, use calculate_tdsr').

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

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

Annotations already declare readOnly, idempotent and closed-world, so safety is covered. The description adds genuinely useful framing beyond that: results are indicative and not legal/financial advice, and the maker is named, which helps an agent caveat output correctly.

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?

Front-loads the verb, resource and scoping axes, then supports with examples. The trailing provenance/disclaimer sentences are useful but slightly padded, keeping it just under maximally tight.

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, and the description does signal that both ABSD and BSD figures come back and that they are indicative. All three parameters are documented at 100% coverage, so an agent has what it needs, with only the precise return shape left implicit.

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 the baseline is 3. The description earns above baseline by tying profile/propertiesOwned combinations to concrete rate outcomes (20% for SC second property, 5% for PR first), adding interpretive meaning the raw enum does not carry.

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 (calculate) and resource (ABSD plus BSD) and the exact scoping axes (buyer profile, number of properties owned). It also implicitly distinguishes itself from the sibling calculate_bsd by noting it returns both ABSD and BSD.

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 two worked examples (SC second property = 20%, PR first = 5%) clarify the context in which each profile/property combination applies, giving the agent concrete usage signal. It stops short of explicitly stating when to prefer calculate_bsd or calculate_ssd instead, so no full 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description is not obligated to restate them. It adds real value by specifying the rate regime in force (15 Feb 2023, 1%–6% bands) and flagging that outputs are indicative, not legal advice.

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?

Front-loads the core purpose, scope, and the calculate_absd routing before any secondary material. The closing marketplace blurb and disclaimer are non-essential padding, but they are short and do not obscure the operational content.

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 usefully previews the return ('tier-by-tier breakdown') and states the rate schedule, applicability, and caveat. It stops short of describing non-residential rates or rounding/currency formatting, a minor gap for a two-parameter calculator.

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 50%: 'price' is documented in the schema while 'propertyType' has an enum and default but no description. The description notes the residential rate schedule and thus implies propertyType matters, but it never explains non-residential treatment or the price-vs-market-value basis beyond the schema's own text, so it only marginally compensates for the gap.

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 (calculate) and resource (Buyer's Stamp Duty for Singapore property purchases), plus the output shape ('tier-by-tier breakdown'). It explicitly differentiates itself from the sibling calculate_absd, so an agent can select between them without opening either 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?

Explicitly routes the agent: BSD applies to every buyer, while foreigners, PRs and owners of other homes additionally owe ABSD and should call calculate_absd 'for the total'. This names the alternative and the condition that selects it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, and the description is fully consistent with a pure calculation tool. It adds genuinely useful context the annotations cannot: the ABSD rate assumptions (SC 20%->0%, PR 30%->5%), the 2.5% p.a. CPF interest assumption via yearsHeld, and the caveat that figures are indicative and not legal or financial advice.

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?

Purpose and comparison are front-loaded in the first sentence, followed by outputs, provider attribution and disclaimer. The provider line is mild promotional padding, but the disclaimer earns its place for a financial-estimate tool; overall it is appropriately sized.

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 carries the burden of explaining returns, and it does so by naming BSD/legal costs, ABSD saved, CPF refund and break-even price. Assumptions and the indicative-figures caveat are also covered, leaving only minor gaps such as how the break-even price should be interpreted.

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 the baseline is 3, but the description adds meaning beyond the schema by explaining the consequence of the profile parameter (ABSD rates differ for sc vs pr) and tying cpfUsed/yearsHeld to the CPF refund calculation. It does not clarify edge cases such as partial shares or the sharePercent transfer mechanics, so it falls short of a 5.

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 (estimate whether decoupling is worth it) and details exactly what is computed: BSD and legal costs versus ABSD saved, plus CPF refund and break-even price. This clearly separates it from siblings like calculate_absd and calculate_bsd, which compute single components rather than the decoupling trade-off.

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 scenario is scoped explicitly ('before buying another property'), giving a clear when-to-use context. It does not, however, name alternative tools (e.g. calculate_absd for a standalone ABSD figure) or state when this tool is the wrong choice, so it stops short of full routing guidance.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower. The description still adds real behavioral context beyond them: it discloses the return shape (results shown both with an agent and selling direct, plus the commission saved) and flags that figures are indicative and not legal/financial advice. It does not state CPF interest assumptions in the prose, but those live in 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?

Three sentences, front-loaded with the actual computation before the extras. The core sentence is dense and earns its place; the brand blurb ("From Propely (propely.sg), the owner-direct condo marketplace") is mild marketing that could be trimmed, and the disclaimer is justified.

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 9-parameter read-only calculator with 100% schema coverage and no output schema, the description compensates well: it names the deducted components, describes what the response contains (both scenarios and the commission saved), and sets expectations on accuracy. An agent has enough to invoke it correctly.

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% across all 9 parameters, with defaults, patterns, and ranges documented, so the schema carries the semantic burden and 3 is the baseline. The description's enumeration of cost components loosely maps to legalFees, outstandingMortgage, cpfPrincipal/cpfInterest, and commissionPercent, but adds no format or edge-case detail (e.g. how purchaseDate/saleDate drive SSD tenure) 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 gives a specific verb ("Estimate") and a precise resource (net cash a Singapore property seller takes home), then enumerates the exact deductions: SSD, legal fees, outstanding mortgage, CPF refund with accrued interest, and agent commission. It is a clear purpose statement, but it never differentiates itself from the sibling calculate_ssd even though SSD is one of its own inputs, leaving an agent to infer the boundary.

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?

Usage is implied by the scenario (a seller estimating proceeds) rather than stated. There is no when-to-use/when-not guidance and no routing to alternatives, despite heavy overlap with calculate_ssd and calculate_decoupling in the sibling set. It does explain that the output covers both the agent-assisted and owner-direct cases, which is mild contextual guidance.

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

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

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds real value on the output side (shows SSD, date it drops to 0, and potential savings from waiting) and sets a disclaimer boundary. It doesn't contradict annotations.

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 core purpose and outputs are front-loaded and dense. The branding sentence ('From Propely (propely.sg), the owner-direct condo marketplace') is promotional filler that doesn't help an agent invoke the tool, costing a point.

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 correctly compensates by enumerating what is returned (SSD amount, zero-date, waiting savings). The purchase/sale date and price inputs are fully covered by the schema, so an agent has enough to call this correctly; only the branding fluff detracts.

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% and all three parameters are self-documented, so the baseline is 3. The description hints that the schedule depends on the purchase date relative to 4 Jul 2025 but adds no syntax or format detail 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?

States a specific verb (calculate) and resource (Seller's Stamp Duty) with a precise scope: selling Singapore residential property within 4 years of purchase. This clearly distinguishes it from siblings like calculate_absd, calculate_bsd, and calculate_seller_net_proceeds without needing to open any 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?

The 'within 4 years of purchase' condition gives a clear triggering context, and the schedule breakdown implies applicability by purchase date. It doesn't explicitly name when to use alternatives (e.g., calculate_bsd for buyer's duty) or state exclusions, so it falls just short of full routing guidance.

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

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

The annotations declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety is covered. The description adds valuable behavioral context: the MAS TDSR limit of 55%, the 70% income counting rule, the stress-test rate default, and the disclaimer that figures are indicative, not legal or financial advice. This goes beyond annotations but does not cover return format or edge cases.

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 two sentences: one explaining the calculation and its key rules, and one providing brand and disclaimer context. It is front-loaded with the core purpose and efficiently covers necessary regulatory details. The second sentence about Propely is slightly promotional but still informative.

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 read-only calculation tool with a detailed input schema and no output schema, the description covers the regulatory context, income counting rules, defaults, and a disclaimer. It omits what the output contains (e.g., pass/fail, maximum loan amount, ratio), but given no output schema, some expectation of return values would be helpful. Overall, it is largely complete for an agent to invoke correctly.

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 the schema fully documents all 8 parameters. The description mentions some semantics (variable/rental income at 70%, stress-test default 4%, tenure default 25) which are already in the schema defaults but reinforces their meaning. No additional syntax or format details are provided 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 states a specific verb ('Check') and resource ('a Singapore home loan against the MAS TDSR limit') and adds a second purpose ('find the maximum loan affordable'). This distinguishes it from siblings like calculate_bsd or calculate_absd, which handle different tax/loan calculations.

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 description implies usage through the regulatory context and mentions income counting rules, but does not explicitly state when to use this tool versus alternatives or what the prerequisites are. It does not name any sibling tools or provide exclusions. The context is clear but lacks explicit usage guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, and the description adds meaningful context on top: the deterministic computation rule, the MAS regulatory basis, and the 'indicative figures, not legal or financial advice' caveat. It stops short of describing the return shape, but for a pure calculation tool this is strong added value.

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?

Front-loaded with the action and formula; the joint-application sentence, disclaimer and source attribution each carry a distinct purpose. The 'From Propely (propely.sg)...' sentence is borderline branding but is short and sets provenance.

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, but the stated formula lets an agent infer the returned tenure value. All four parameters are covered by the schema plus the description's rule explanation, so nothing needed to call it correctly is missing, though an explicit statement of the return format would complete it.

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 genuinely adds meaning: it explains that borrower1Age enters the '65 minus age' rule and that the income fields produce an income-weighted average age for joint applications, telling the agent why the numeric parameters matter.

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 ('Work out the longest home loan tenure MAS allows for private residential property in Singapore') and even gives the governing formula, so the agent can tell it apart from siblings like calculate_tdsr or calculate_absd 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?

It clarifies the joint-application path ('also give the second borrower', income-weighted average age), which is useful context, but it never says when to prefer this over the other loan-related siblings (calculate_tdsr) or states any exclusion. Usage is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety and determinism are covered. The description adds genuinely useful behavioral context beyond that: the units (percent per year), the as-of date accompanying the values, and the data source (Propely), which tell the agent how to interpret and cite the result. It still does not state update frequency or whether a single snapshot vs. history is returned.

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?

Three sentences, front-loaded with the actual returned data and followed by units and source. The home-loan pricing sentence is mildly tangential to invocation but does help the agent judge relevance; the attribution sentence is short and harmless.

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 carries the burden of describing the return, and it does so adequately: which two tenors, the unit, and the as-of date. The main residual gap is freshness/update cadence and whether historical values are available, but nothing essential to calling a zero-argument tool is missing.

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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the schema to document and nothing for the description to compensate for.

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 precise resource (1-month and 3-month compounded SORA for Singapore), the units (percent per year), and the accompanying as-of date, so an agent knows exactly what it fetches. It implicitly separates itself from the sibling calculators (TDSR, BSD, ABSD) by being a pure rate lookup, though it never explicitly contrasts itself with them.

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?

Usage is only implied: the note that Singapore floating-rate home loans are priced as SORA plus a bank spread hints at why an agent would want the rate, but there is no explicit when-to-use, when-not-to-use, or reference to any sibling tool such as calculate_tdsr.

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