Skip to main content
Glama

AVnester — Indian Real Estate Intelligence

Estimate stamp duty + registration (calculator)

estimate_stamp_duty_and_registration
Read-onlyIdempotent

Estimate Indian state stamp duty + registration charges on a property purchase. Supports all 28 states + 8 UTs with buyer-gender concessions, urban/rural overrides, and commercial/agricultural multipliers. Pass constructionStatus to also itemize GST (under-construction 1%/5%, ready/resale 0%) for an all-in statutory quote. Returns supported=false for states outside India (supported set named in rateBasis). Not legal/tax advice. Always surface the disclaimer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateNoIndian state — accepts ISO code ("MH"), URL slug ("maharashtra"), or display name ("Maharashtra"). All 28 states + 8 UTs supported.Tamil Nadu
isUrbanNoWhether property is in an urban/metro area — gates metro-cess surcharges (e.g., Mumbai LBT, BBMP cess).
buyerGenderNoBuyer gender — overrides isWomanBuyer when set. "joint" = man+woman jointly owned.
isWomanBuyerNoBackward-compatibility shim — prefer buyerGender. When true, internally treated as buyerGender="female".
propertyTypeNoProperty type — applies state-specific multiplier (commercial/agricultural).
propertyValueYesSale value in INR for stamp-duty calculation.
carpetAreaSqftNoCarpet area (sqft) — with value, decides the affordable-housing 1% GST slab.
constructionStatusNoWhen set, also itemizes GST: under-construction = 1% (affordable) / 5%; ready/resale = 0%. Omit → GST not computed.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
gstNo
cardsYes
stateYes
totalYes
rateBasisYes
stampDutyYes
supportedYes
disclaimerYes
attributionYes
totalWithGstNo
propertyValueYes
registrationFeeYes
rateEffectiveDateYes

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already indicate readOnly, idempotent, openWorld, and non-destructive. Description adds behavioral details: handling of states outside India (supported=false), GST itemization based on constructionStatus, and buyer-gender concessions. 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.

Conciseness5/5

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

Four sentences, no wasted words. Front-loaded with purpose, then key features, special case, and disclaimer. Each sentence contributes meaning.

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?

Given 8 parameters, 100% schema coverage, and existence of output schema, the description covers main functionality, edge cases (supported=false for non-India), and offers a customer-facing disclaimer. Could mention rateBasis set but is implied. Complete enough.

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 100%, so baseline is 3. Description adds value by explaining the effect of parameters (e.g., 'urban/rural overrides', 'commercial/agricultural multipliers') and provides a usage hint for constructionStatus to get GST. This goes beyond schema descriptions.

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 Indian state stamp duty and registration charges, using specific verb 'Estimate' and resource 'stamp duty + registration'. It distinguishes from siblings like calculate_home_affordability or compare_properties by focusing on statutory charges.

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?

Description provides context for usage (property purchase in India) and includes a disclaimer ('Always surface the disclaimer'), but does not explicitly state when not to use this tool or compare with alternatives among siblings.

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

Try in Browser

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