AVnester — Indian Real Estate Intelligence

Home purchase decision intelligence

get_property_decision_intelligence

Read-onlyIdempotent

Assess whether a buyer can afford a specific Indian home — ONE verdict (AFFORDABLE / STRETCH / NOT_YET / INELIGIBLE) combining indicative eligibility (FOIR/LTV/CIBIL), EMI, true cash-to-close (down payment + stamp duty + registration + itemized GST), regime-aware tax, and an indicative lender-fit triage. Mode A: listingId (Coimbatore/Chennai catalog). Mode B: propertyValue + state (any Indian state). NOT a loan approval, offer, or advice. Always surface the disclaimer.

Input Schema

TableJSON Schema

Name	Required	Description
`state`	No	Indian state (ISO "MH"/slug/name) for stamp duty. Required in manual mode; ignored in listing mode.
`isUrban`	No	Urban/metro — gates metro-cess surcharges in stamp duty.
`assetType`	No	"home" (flat/villa/house) or "plot" (bare land); manual mode only. Plot → shorter tenure, no home-loan tax benefit.
`jointLoan`	No	Joint home loan — doubles 80C/24b caps (equal split).
`listingId`	No	AVnester listingId (Coimbatore/Chennai catalog). Listing mode — do NOT also pass propertyValue (rejected) or state (ignored).
`annualRent`	No	Annual rent received (let-out).
`cibilScore`	No	Numeric CIBIL score. Omit → eligibility stays indicative.
`buyerGender`	No	Buyer gender — affects stamp duty in states with a women concession.
`tenureYears`	No	Loan tenure in years. Defaults to 20.
`propertyValue`	No	Property price in INR (manual mode). Pass with state; not with listingId.
`carpetAreaSqft`	No	Carpet area (sqft) — sharpens the affordable-housing GST test (with the ₹45L value cap).
`employmentType`	No	Employment type (affects tax standard deduction).
`occupancyIntent`	No	Self-occupied vs let-out — changes §24(b) interest treatment. Omitted → self-occupied.
`residencyStatus`	No	Residency status.
`monthlyNetIncome`	Yes	Buyer monthly take-home income in INR.
`savingsAvailable`	No	Liquid cash for down payment + charges — enables the cash-gap calc.
`annualIncomeForTax`	No	Annual income for tax. Defaults to monthlyNetIncome × 12.
`existingMonthlyEmis`	No	Existing monthly loan EMIs in ₹ (car/personal/cards). Omitted → assumed ₹0, which can inflate eligibility and flip the verdict — ask the buyer.
`interestRatePercent`	No	Override annual interest rate. Defaults to indicative market rate.
`isUnderConstruction`	No	Under-construction → GST applies; ready-to-move → no GST. Omitted → ready-to-move (no GST).
`coApplicantMonthlyIncome`	No	Co-applicant monthly income (joint affordability).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`emi`	No
`tax`	No
`mode`	No
`cards`	Yes
`trust`	No
`verdict`	No
`notFound`	No
`warnings`	No
`assetType`	No
`lenderFit`	No
`disclaimer`	Yes
`assumptions`	No
`attribution`	Yes
`eligibility`	No
`affordability`	No
`stampDutySupported`	No

TDQS

A4.4/5.0

Behavior4/5

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

Given annotations already declare readOnly/openWorld/idempotent, the description adds substantial behavioral context: it produces a single verdict that is 'indicative', combines multiple financial components, and explicitly disclaims loan approval status. It also discloses the need to surface a disclaimer, which is not in the annotations.

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?

The description is dense but compact, using a long first sentence to enumerate key computations, then clear mode separation and disclaimers. No filler words; every clause adds information. Slightly long but appropriate for the tool's complexity.

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?

With an output schema present, the description does not need to explain return values. It covers purpose, modes, disclaimers, indicative nature, and key computation components, which is comprehensive for a 21-parameter tool. The schema already handles individual parameter details, so the description fills the conceptual gaps (modes, exclusions) effectively.

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?

The input schema covers 100% of parameters, so baseline is 3. The description adds value by framing how parameters are grouped into Mode A (listingId) vs Mode B (propertyValue + state), and by explaining that cash-to-close includes itemized GST and stamp duty components, which helps the agent understand which parameters matter in each mode.

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 starts with a specific verb ('Assess whether a buyer can afford') and clearly defines the output as ONE verdict with enumerated possible values. It distinguishes this tool by combining eligibility, EMI, cash-to-close, tax, and lender-fit triage, differentiating it from simpler sibling tools like calculate_home_affordability.

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 explicitly defines two mutually exclusive modes (listingId vs propertyValue+state) and provides clear constraints (e.g., 'any Indian state', 'Coimbatore/Chennai catalog'). It also states exclusions ('NOT a loan approval') and a required action ('Always surface the disclaimer'), giving usable when-to-use guidance without naming sibling alternatives.

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

All AVnester — Indian Real Estate Intelligence tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: search, details, comparisons (localities vs. listings), and specific financial calculations (EMI, stamp duty, tax, prepayment, balance transfer, decision intelligence). Descriptions clearly differentiate between similar-sounding tools like calculate_home_affordability and get_property_decision_intelligence.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., compare_properties, get_locality_insights, simulate_loan_prepayment). The verbs are descriptive and uniform in style, with no mixed conventions or vague names.

Tool Count5/5

11 tools is well-scoped for a real estate intelligence server, covering property search, locality analytics, and financial calculators. Each tool has a clear purpose and the set feels neither sparse nor bloated.

Completeness5/5

The tool surface covers the full home-buying journey in India: searching properties, getting details, comparing localities/listings, estimating stamp duty and loan payments, optimizing tax regime, simulating prepayment, and assessing overall affordability with decision intelligence. No obvious gaps or dead ends.

Resources

Need Help?