AVnester — Indian Real Estate Intelligence

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

The description adds behavioral context beyond annotations: states it's deterministic math, not advice, mentions the assumptionNote and disclaimer fields, and clarifies it does not constitute a loan approval. This complements the readOnlyHint and idempotentHint 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 description is three sentences, front-loading the core purpose, then adding mode and behavioral details. Every sentence adds value without redundancy.

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?

Given the presence of an output schema, the description need not detail return fields. It covers purpose, modes, disclaimers, and behavioral caveats, making it complete for a calculator tool.

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?

With 100% schema coverage, baseline is 3, but the description adds significant meaning: explains the 80% LTV assumption for propertyValue, distinguishes propertyValue vs loanAmount modes, and states defaults for loanAmount, tenureYears, and interestRatePercent. This goes beyond the schema descriptions.

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 clearly states it estimates monthly home-loan EMI, with the title 'Estimate home-loan EMI (calculator)'. It distinguishes from sibling tools like simulate_loan_prepayment or compare_balance_transfer by being a simple deterministic calculator.

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 explains two modes (propertyValue vs loanAmount) and when to use each, e.g., 'pass propertyValue (80% LTV assumed) OR loanAmount for a specific loan'. It also notes the tool is for 'what would my EMI be'. However, it does not explicitly state when not to use it or compare to specific siblings.

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 description reveals critical behavioral traits beyond annotations: it is 'pure deterministic math', provides no advice or loan-approval claim, and lists the exact outputs (new EMI, interest saved, etc.). It also mandates surfacing the disclaimer. These details add significant value beyond the readOnlyHint and idempotentHint 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 description is concise and well-structured: three sentences covering purpose, behavioral transparency, and usage/output. Every sentence adds value with no redundancy.

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?

The description covers purpose, usage, transparency, outputs, and disclaimer. Given the presence of output schema and comprehensive annotations, it is mostly complete. Minor omission: does not explicitly state it's for home loans (though implied), but overall sufficient.

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 baseline is 3. The description does not add per-parameter details beyond what the schema already provides. However, it does explain the overall calculation context, which indirectly supports parameter understanding.

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 clearly states the tool's purpose: comparing staying on current home loan vs transferring to a lower rate. It uses specific verbs ('compare', 'returns') and identifies the resource ('home loan balance transfer'). The purpose is distinct from sibling tools like simulate_loan_prepayment.

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?

Explicit usage guidance is provided: 'Use when the user asks "should I switch lenders / transfer my loan / refinance".' It also clarifies when not to use ('no advice, no loan-approval claim'), but does not explicitly mention alternative tools.

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, openWorldHint. Description adds behavior for out-of-scope cities (supported=false) and mentions surfacing scopeMessage, which is useful beyond 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?

Three sentences: first sets purpose, second defines usage, third handles edge cases and sibling. No filler, front-loaded.

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 full schema coverage, output schema (unseen but present), and clear behavioral notes, the description is complete for an agent. Covers when, what, and error states.

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 covers all parameters with descriptions (100% coverage). Description adds a note about Coimbatore focus, but city param allows any Indian city, causing minor inconsistency. Baseline 3 is appropriate as schema handles semantics.

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 uses a specific verb ('Compare'), resource ('localities'), and scope (2–3, side-by-side with metrics). It also distinguishes from sibling compare_properties by specifying comparison of localities vs. listings.

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 states when to use: user asks 'X vs Y' or 'which is better' for Coimbatore neighborhoods. Also provides exclusion criteria (out-of-scope cities) and directs to compare_properties for listing comparisons.

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 mark it readOnly, idempotent, non-destructive. Description adds details: returns pricePerSqft, vsCheapestPercent, vsLargestAreaPercent; picks best 5 if overflow; unknown IDs return not_found_or_unpublished; Coimbatore-only. No contradiction.

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?

Efficient and front-loaded; each sentence adds value. Slight redundancy with schema but minimal.

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?

Given full schema and annotations, description covers all behavioral aspects: usage constraints, edge cases (overflow, unknown IDs), non-recommendation note. Complete for this complexity.

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 covers 100% of parameter (listingIds) with description matching the tool description. No additional semantic value beyond 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 clearly states it compares 2-5 AVnester listings by listingId side-by-side, distinct from sibling tools like search_properties (search) and compare_localities (localities).

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 says to get IDs from search_properties first, handles overflow by selecting 5 most relevant, states does not recommend a purchase, but does not explicitly name alternative tool for recommendations.

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 indicate the tool is read-only and idempotent. The description adds behavioral details: it returns supported=false for non-Indian states, computes GST only when constructionStatus is provided, and states it is not legal advice. No contradictions 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?

The description is concise with 4-5 sentences, no wasted words. It front-loads the core purpose and progressively adds details in a logical order: states, concessions, GST, edge cases, disclaimer. Every sentence earns its place.

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?

Given the output schema exists, the description covers all major aspects: state support, gender, urban/rural, property type, GST computation conditions, and disclaimer. It also mentions the edge case of non-Indian states returning supported=false. Complete for an 8-parameter tool.

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. The description adds meaning by summarizing how parameters interact (e.g., buyerGender overrides isWomanBuyer, constructionStatus enables GST) and explains high-level behavior, going beyond the individual parameter descriptions.

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 clearly identifies the tool as an estimator for Indian state stamp duty and registration charges, covering all states/UTs, gender concessions, urban/rural, property types, and GST. It distinguishes itself from sibling tools which focus on affordability, loan comparison, or property search.

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 provides clear context on when to use the tool (for stamp duty estimation) and how to use parameters (e.g., constructionStatus for GST). While it does not explicitly list when not to use it or alternatives, the sibling tools are obviously different, making the usage context clear.

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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about out-of-scope cities returning supported=false and surfacing scopeMessage, plus always surfacing the disclaimer for livability/investment grade. 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?

Four sentences, each serving a purpose: first defines output, second gives usage cue, third handles out-of-scope, fourth mandates disclaimer. No redundant words or fluff.

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?

Given output schema exists (so return values not required), the description covers all critical aspects: what the tool does, when to use, edge-case behavior for unsupported cities, and a mandatory display rule. No gaps for the complexity level.

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% with clear descriptions for both parameters. The description indirectly adds value by specifying 'Coimbatore locality', hinting at city constraints, but does not override or enhance schema details significantly.

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 clearly states the verb 'Get' and resource 'aggregated insights for a Coimbatore locality', listing specific output fields. It distinguishes from sibling tools like compare_localities or get_property_details by focusing on a single locality's market insights.

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 provides when to use: 'when the user asks "what is X locality like" about a Coimbatore neighborhood.' Also covers out-of-scope behavior and mandatory disclaimer for specific grades, offering clear usage guidance without ambiguity.

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?

No contradiction with annotations. Adds that it is not a loan approval/offer/advice and must surface a disclaimer. Annotations already declare readOnly, idempotent, and non-destructive; the description supplements with real-world behavioral constraints.

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 dense and informative but structured as a single run-on sentence with parentheticals. Bullet points or clearer separation of modes would improve readability without losing 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?

Given 21 parameters, full schema coverage, and an output schema, the description adequately covers what the tool does, the verdict categories, and key factors. It does not need to explain return values, so it is complete for the AI's needs.

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% (baseline 3). The description adds value by explaining the two modes (listingId vs propertyValue+state) and the overall computation approach, helping the AI understand parameter relationships without repeating schema details.

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 clearly states the tool's purpose: 'Assess whether a buyer can afford a specific Indian home — ONE verdict (AFFORDABLE / STRETCH / NOT_YET / INELIGIBLE)' and lists the combined factors. It distinguishes two modes (listingId vs propertyValue+state), setting it apart from siblings 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes two usage modes with clear parameter requirements, and notes what the tool is NOT (loan approval/offer/advice). Does not directly contrast with siblings, but the context is sufficient for an AI to decide when to invoke 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?

Adds beyond annotations: never throws (returns null/notFound), avoids leaking existence, and notes Coimbatore-only catalog. Annotations already indicate read-only, idempotent, open-world, non-destructive.

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 concise sentences, each adding essential information. No fluff, well front-loaded with purpose.

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?

Fully covers input source, edge cases (unknown IDs), read-only nature, and geographic scope. Output schema exists, so return details not required.

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 provides 100% coverage with description; description adds context: IDs not guessable, come from search_properties, and are trailing segment of sourceUrl.

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?

Clearly states it fetches full public details for one AVnester listing by listingId. Distinguishes from sibling search_properties and other tools.

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 instructs to get listingId from search_properties first, notes IDs are not guessable, and specifies when to use (user references a specific listing). Also provides geographic scope (Coimbatore-only).

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 indicate safe, idempotent, read-only. Description adds it's 'pure deterministic slab math—not tax advice' and lists modeled and non-modeled benefits. No contradiction.

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?

Single paragraph with front-loaded purpose and usage cues. Can be considered concise, though it could benefit from bullet points. Every sentence adds value.

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?

Given 18 parameters and NRI variants, the description focuses on core use and limitations. Schema handles parameter details. Sufficient for an AI agent to understand scope.

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% with descriptions. Description adds context by linking parameters to tax sections (e.g., homeLoanInterest to §24(b)) and mentioning joint-loan doubling. Adds value beyond 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?

Clearly states it compares old vs new tax regimes for home loan borrowers and recommends the better one. Distinct from sibling tools which are property calculations, not tax advice.

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 lists trigger phrases like 'old or new tax regime', 'home-loan tax benefit', and mentions what is not modeled (capital gains, HRA) to set expectations. Also instructs to surface disclaimer.

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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint all appropriate. Description adds return format (sanitized cards, handoff URLs, verified flag), that seller contact details are never returned, and out-of-scope city error handling. No contradictions.

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?

Four sentences, front-loaded with purpose, then usage, return behavior, and error handling. Every sentence adds information without redundancy.

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?

Given output schema likely exists, description covers error conditions (out-of-scope), return format, and key behavioral constraints. For a complex search tool with 9 parameters, this is complete enough.

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 baseline is 3. Description adds context for limit ('v1 abuse defense') and hints at typical usage. This adds modest value beyond 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?

Description clearly states verb (Search) and resource (residential property listings) with geographic scope (Coimbatore, Tamil Nadu). This distinguishes it from sibling tools like get_property_details and compare_properties.

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 says to use when user names a locality, price band, BHK, or transaction type. Also describes behavior for out-of-scope cities. Could be improved by explicitly listing when not to use (e.g., 'use get_property_details for specific property info').

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 description adds context beyond annotations by stating 'Pure deterministic math — no advice, no loan-approval claim' and requiring to 'Always surface the disclaimer field.' This reveals important behavioral traits (deterministic, non-advisory) that annotations (readOnlyHint, idempotentHint) do not fully capture.

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 a single paragraph that covers the essential purpose, modes, and disclaimer. It is fairly efficient but could be more structured (e.g., bullet points for modes) to improve readability without losing information.

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?

Given the tool's complexity (8 parameters, 2 enums, output schema present), the description covers core usage, modes, comparison, and disclaimer. The output schema fills in return value details, making the definition complete for an agent to correctly invoke the tool.

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?

Although the schema already provides descriptions for all 8 parameters (100% coverage), the description adds significant meaning by explaining how prepayment modes (one_time, recurring, etc.) work and the comparison between reduce_tenure and reduce_emi. This goes beyond the schema to aid correct parameter usage.

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 clearly states it simulates prepaying an Indian home loan, listing specific use cases like 'should I prepay' and modes such as one-time or recurring. It distinguishes itself from sibling tools (e.g., property search, affordability calculators) by being a calculator specific to prepayment scenarios.

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 explicitly states 'Use for...' with several scenarios (e.g., 'should I prepay', 'pay extra each month'), making it clear when to use the tool. However, it does not explicitly mention when not to use it or suggest alternative sibling tools for other purposes.

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