AVnester — Indian Real Estate Intelligence

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

No annotations provided, so description carries full burden. It discloses deterministic math, no advice, no eligibility claim, and mentions response includes an 'assumptions' field documenting default 80% LTV and a disclaimer field. Does not cover error handling or edge cases, but is sufficiently transparent for typical use.

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?

Description is a single paragraph of four sentences, front-loaded with purpose. It is clear and contains no fluff, though could be slightly more concise. Overall efficient.

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 simple calculation tool with 4 params and no output schema, the description covers purpose, use case, deterministic nature, defaults, and instructions to surface disclaimer. It provides sufficient context for correct agent invocation.

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. Description adds minimal value beyond schema: it reiterates the default 80% loan-to-value for loanAmount, which is already in schema. No additional semantic guidance for other parameters.

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 it estimates monthly home-loan EMI for a property value in India. It specifies the tool is deterministic math and distinguishes from siblings by clarifying it offers no advice, recommendation, or eligibility claims. The verb 'estimate' and resource 'EMI for property value' are specific and unambiguous.

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: when user asks 'what would my EMI be' or wants to compare loan scenarios. It implies what not to use for (no advice/eligibility), but does not name alternatives among sibling tools. Context is clear but lacks explicit exclusions.

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?

Discloses that the tool performs pure deterministic math, provides no advice or loan-approval claim, and instructs to always surface the disclaimer field. Given no annotations, this covers the behavioral aspects well.

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: purpose, usage, returns/instruction. Every sentence adds value, no wasted words.

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?

Lists return values (EMI, interest saved, switching cost, net saving, breakeven month) despite no output schema. Does not mention assumptions or edge cases, but sufficient for a straightforward comparison 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 description coverage is 100%, so baseline is 3. The description adds default values for flatCosts and processingFeePct, but no additional meaning 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 clearly states the tool compares staying on current loan versus transferring to a lower rate, specifying the verb 'Compare' and the resources. It differentiates from sibling tools like calculate_home_affordability or compare_localities by focusing on refinancing.

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 use when user asks about switching lenders, transferring loan, or refinancing. Does not mention when not to use or alternatives, but the guidance is clear and actionable.

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 annotations provided, so description carries full burden. Discloses scope (Coimbatore only, other cities on roadmap) and out-of-scope behavior (supported=false). Could mention data source freshness or error handling, but overall transparent.

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: first gives purpose and scope, second gives usage guidance and fallback. Front-loaded, no redundancy. 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?

Covers input constraints, scope, and out-of-scope behavior. No output schema, but description lists compared categories (price, livability, etc.) giving agent idea of return content. Missing return format details but acceptable.

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%, but description adds extra guidance: 'array, not comma-separated string' for localities, and implies city must be Coimbatore. Adds value beyond 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?

Description clearly states verb 'compare' and resource 'localities' with specific metrics (price trends, livability, etc.). Distinguishes from sibling compare_properties by specifying it's for 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 tells when to use: user asks 'X vs Y' or 'which is better' about Coimbatore neighborhoods. Also tells when not to use: out-of-scope cities return supported=false, and provides alternative tool compare_properties for listings.

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?

With no annotations, the description fully discloses behavior: unknown IDs return 'not_found_or_unpublished', returns listings with objective metrics, does not recommend purchase, and instructs to surface the disclaimer field.

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 pack all necessary information without redundancy. Front-loaded with main action and constraints, 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 the tool has only one parameter and no output schema, the description covers input constraints, output structure, error handling, and a critical usage instruction (surfacing disclaimer), making it complete for correct invocation.

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 schema coverage is 100%, the description adds meaning by specifying the IDs are from AVnester Coimbatore catalog and that unknown IDs behave a certain way, enriching the parameter context 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 clearly states the tool compares 2-5 AVnester listings by ID, specifies the catalog scope (Coimbatore-only), and distinguishes from siblings like 'compare_localities' by focusing on specific listings with IDs.

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 'Use when the user names specific listings,' providing good guidance. However, it does not mention when not to use it or contrast with alternatives beyond what siblings imply.

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?

With no annotations, the description provides important behavioral details: returns supported=false and zero numerics for non-Indian states, includes a disclaimer field, and notes that it is not legal/tax advice. It also mentions state-specific overrides and multipliers. However, it does not fully describe the output structure beyond a few fields.

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 multiple short sentences, each adding distinct value: purpose, supported regions, behavior for invalid inputs, and disclaimers. No redundant or wasted text.

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 no output schema, the description explains key return elements (supported, disclaimer, zero numerics) and covers all six input parameters via schema. It lacks a full return object specification, but is otherwise complete for decision-making.

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 adds context about gender concessions, urban/rural overrides, and property type multipliers, which map to parameters, but does not add new meaning beyond the schema's own 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 specifies 'Estimate Indian state stamp duty + registration charges on a property purchase,' making the verb and resource clear. It distinguishes from sibling tools like calculate_home_affordability and compare_properties by focusing on a specific tax estimation.

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 clearly indicates when to use the tool (for property purchase stamp duty estimation) but does not explicitly state when not to use it or provide alternative tool references. The context is clear enough, though explicit exclusions would improve 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?

No annotations are provided, so the description carries full behavioral disclosure burden. It discloses key behaviors: out-of-scope cities return supported=false (surface scopeMessage to user), and the disclaimer field must be surfaced when returning livability/investment grade. No contradictions or missing critical behavioral info.

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: first sentence lists all outputs, second sentence provides usage guidance and critical behavioral notes. Front-loaded with purpose, no filler or redundant 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 no output schema, the description thoroughly enumerates return fields (avg price, supply count, demand pulse, livability/investment grade, highlights, watchouts, priceTrends, strengthTags) and includes edge-case handling (supported, scopeMessage, disclaimer). Fully covers the tool's data 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 description coverage is 100%, baseline 3. The description adds value by explaining that the city input is currently limited to Coimbatore (with roadmap for other Indian cities), which is important context not captured in the schema alone.

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 ('Get') and resource ('aggregated insights for a Coimbatore locality'), lists multiple specific outputs (avg price, supply count, etc.), and clearly distinguishes from sibling tools like compare_localities or search_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?

The description explicitly states when to use ('when the user asks "what is X locality like" about a Coimbatore neighborhood') and notes out-of-scope cities return supported=false. It could further contrast with sibling tools like compare_localities, but the usage context is 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?

No annotations are present, so the description carries full burden. It clarifies the tool is not a loan approval/offer/advice and requires a disclaimer. However, it does not disclose behavioral traits like data sources, error conditions, idempotency, or caching. This is a moderate disclosure.

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 but clearly structured: purpose first, then modes, then caveat. It is not overly verbose, though some phrasing could be tightened. Front-loads the core action effectively.

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 19 parameters, no output schema, and moderate complexity, the description covers the verdict output but does not detail the full return structure (e.g., whether it returns EMI breakdown, tax calculations). It is functional but leaves the agent guessing about additional outputs.

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. The description adds value beyond schema by explaining the exclusive-or relationship between listingId and propertyValue+state, and notes state-specific effects like buyerGender affecting stamp duty. This exceeds mere schema repetition.

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 assesses affordability with a specific verdict (AFFORDABLE/STRETCH/NOT_YET/INELIGIBLE) combining multiple factors. It names two distinct modes (listingId or propertyValue+state), making the tool's purpose precise and distinct 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?

The description explains when to use the tool (assess affordability) and describes two modes, but does not explicitly state when not to use it or provide direct comparisons with sibling tools like calculate_home_affordability. Guidance is adequate but lacks exclusions.

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 annotations provided, so description fully handles disclosure. It states read-only, no side effects, returns notFound:true for missing/unpublished IDs, and never throws errors. This is comprehensive.

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, no wasted words, front-loaded with main purpose, then constraints and usage examples. Highly efficient.

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 simplicity (1 param, no output schema), the description covers purpose, usage, parameter format, edge cases (notFound, unpublished), geographic constraint, and behavioral guarantee.

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 has 100% coverage for the single parameter. Description adds valuable context: 'AVnester listing ID (UUID or slug from the public sourceUrl path),' which enhances understanding 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 clearly states 'Fetch full public details for a single AVnester property listing by its listing ID,' specifying the action, resource, and identifier. It distinguishes from siblings like search_properties by focusing on a single listing.

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?

Provides explicit guidance: 'Use when the user references a specific listing (e.g., "show me AVN-DEMO-1001")' and notes geographic limitation. Could explicitly mention alternatives like search_properties for broad queries.

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 annotations exist, so the description carries full burden. It discloses that it is 'pure deterministic math' (not tax advice), lists modeled items and omissions, and mentions the disclaimer field. It does not explicitly state that it is read-only, but that is implied. No side effects or latency mentioned, which is acceptable for a calculation tool.

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 cover purpose, usage trigger, modeling scope, and limitations. Every sentence serves a purpose with no redundancy. Information is front-loaded and well-structured, making it easy for an AI agent to parse quickly.

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 10 parameters with full schema coverage and no output schema, the description explains what it computes and its limitations but does not detail the output format or structure. For a decision tool, the output is implied (recommendation with disclaimer). Sibling tools are not closely related, so context is 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?

The description adds significant meaning beyond the input schema, e.g., clarifying that homeLoanInterest and homeLoanPrincipal are modeled under specific sections, and that jointLoan doubles caps under equal-split assumption. It also notes that annualIncome excludes house property, which is not in the schema description. Schema coverage is 100% and the description fills in contextual 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?

Description starts with a clear action ('Compare income tax...recommend which saves more') and specifies the exact scenario (home-loan borrower, FY2026-27). It lists trigger phrases for use, which distinguishes it from sibling tools like calculate_home_affordability and compare_balance_transfer.

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 'Use when the user asks...' with specific queries, and lists what it does NOT model (capital gains, HRA), providing clear when-not-to-use guidance. Sibling tools are not named but the context makes differentiation obvious.

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?

Discloses key behaviors: returns sanitized listing cards, never returns seller contact details, and for out-of-scope cities returns supported=false with scopeMessage. Without annotations, this provides essential behavioral context.

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 concise sentences covering purpose, usage, behavior, and edge cases. No redundant information; each 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?

Covers scope, usage triggers, return format, and error handling. Missing details on pagination, default parameter values, and what 'sanitized' entails. Adequate for a search tool but could be more comprehensive.

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 descriptive parameter descriptions. The tool description does not add significant semantics beyond the schema, so a baseline score of 3 is appropriate.

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 it searches verified residential property listings in Coimbatore, providing a specific verb and resource. It distinguishes from sibling tools like compare_localities or get_locality_insights, which serve different purposes.

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 tells when to use the tool: 'when the user names a Coimbatore locality, price band, BHK, or transaction type.' It does not list alternative tools for out-of-scope but provides clear usage context.

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 annotations are provided, so the description fully bears the transparency burden. It discloses the tool is 'pure deterministic math — no advice, no loan-approval/eligibility claim,' which is honest. It also mentions comparing two strategies. However, it instructs to 'always surface the disclaimer field' without specifying where that field appears (likely in output), which is a minor gap.

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 concise sentences, front-loaded with purpose and behavior, followed by usage guidance, then strategy details, and a final instruction. Every sentence earns its place 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?

While parameter semantics are well-covered, the lack of an output schema means the description should explain return values or format. The mention of a 'disclaimer field' is ambiguous without describing the response structure. For a 7-parameter simulation tool, this is a noticeable gap.

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%, and the description adds value by explaining the strategy options ('reduce_tenure... bigger saving'), default behavior for annualRatePercent, and prepayment mode implications. This goes beyond the schema's brief 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 the tool simulates the impact of prepaying an Indian home loan, using specific verbs like 'Simulate' and identifying the resource ('Indian home loan'). It distinguishes from siblings like calculate_home_affordability and compare_localities, which address different financial questions.

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 lists user queries that trigger this tool (e.g., 'should I prepay', 'reduce EMI or tenure'), providing clear when-to-use guidance. It does not explicitly state when not to use it, but the context is well-defined.

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