AVnester — Indian Real Estate Intelligence

Estimate home-loan EMI (calculator)

calculate_home_affordability

Read-onlyIdempotent

Estimate the monthly home-loan EMI / monthly payment in India — a home-loan calculator. Deterministic math; not advice or a loan-approval claim. Two modes: pass propertyValue (80% LTV assumed) OR loanAmount for a specific loan (e.g. "₹50 lakh loan"). Use for "what would my EMI be" / "monthly payment on …". The response assumptionNote states the basis in plain words. Always surface the disclaimer field.

Input Schema

TableJSON Schema

Name	Required	Description
`loanAmount`	No	Loan amount in INR. Pass this when the user states a specific loan (e.g. "₹50 lakh loan") rather than a property price. Defaults to 80% of propertyValue if omitted.
`tenureYears`	No	Loan tenure in years. Defaults to 20.
`propertyValue`	Yes	Property value (price) in INR. When the user states a property/home price, put it here — an 80% loan is assumed unless loanAmount is also given.
`interestRatePercent`	No	Annual interest rate (percent). Defaults to current market estimate.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`emi`	Yes
`cards`	Yes
`disclaimer`	Yes
`loanAmount`	Yes
`assumptions`	Yes
`attribution`	Yes
`tenureYears`	Yes
`totalPayment`	Yes
`totalInterest`	Yes
`assumptionNote`	Yes
`inputPropertyValue`	Yes
`interestRatePercent`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and not destructive. The description adds value by clarifying it is 'deterministic math; not advice or a loan-approval claim' and mentions the response includes assumptionNote and disclaimer, which goes beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with 5 sentences, each serving a purpose (purpose, nature, usage modes, output hint). It is front-loaded with the main action and free of unnecessary words.

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?

Given the tool's complexity (4 parameters, output schema present), the description covers the two modes, mentions response fields (assumptionNote, disclaimer), and specifies geographic context (India). It is complete for an agent to correctly invoke this tool.

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 description coverage is 100%, so the baseline is 3. The description reiterates the mode distinction (propertyValue vs loanAmount) but adds no substantial new meaning beyond what the schema already explains about each parameter.

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 clearly states it estimates monthly home-loan EMI for India, using specific verbs like 'estimate' and defining resource as 'home-loan calculator'. It distinguishes from sibling tools by specifying it's for EMI calculation, not comparisons or other fees.

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?

The description explicitly states when to use it ('what would my EMI be' / 'monthly payment on …') and explains the two modes (propertyValue or loanAmount). While it doesn't list when not to use or directly compare to siblings, the context is clear given the sibling names.

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?