mcp-india-stack

Overview Schema Source Related Servers Discussions Admin

calculate_home_vs_rent

Read-onlyIdempotent

Decide whether to buy or rent a home by comparing financial outcomes, including loan costs, rent, property appreciation, and investment returns, with a yearly breakdown and break-even analysis.

Instructions

Compare buying vs renting financial outcome.

Use when deciding between buying a home or renting.

Args: home_price: Property price in INR down_payment_percent: Down payment as % loan_interest_rate: Home loan interest rate % loan_tenure_years: Loan tenure monthly_rent: Current monthly rent annual_rent_increase: Expected rent increase %/year expected_property_appreciation: Property appreciation %/year investment_return: Return on invested down payment % analysis_years: Years to compare

Returns: Buy/rent comparison with yearly breakdown and break-even analysis.

Input Schema

TableJSON Schema

Name	Required	Description
`home_price`	Yes	Property price in INR
`monthly_rent`	No	Current monthly rent in INR
`analysis_years`	No	Years to compare
`investment_return`	No	Return on invested down payment percentage
`loan_tenure_years`	No	Loan tenure in years
`loan_interest_rate`	No	Home loan interest rate percentage
`annual_rent_increase`	No	Expected rent increase percentage/year
`down_payment_percent`	No	Down payment as percentage
`expected_property_appreciation`	No	Property appreciation percentage/year

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv0.5.0Aug 25, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / analysis_years / title
```
Added value: +"Analysis Years"
```
- addedInput schema / properties / annual_rent_increase / title
```
Added value: +"Annual Rent Increase"
```
- addedInput schema / properties / down_payment_percent / title
```
Added value: +"Down Payment Percent"
```
- addedInput schema / properties / expected_property_appreciation / title
```
Added value: +"Expected Property Appreciation"
```
- addedInput schema / properties / home_price / title
```
Added value: +"Home Price"
```
- addedInput schema / properties / investment_return / title
```
Added value: +"Investment Return"
```
- addedInput schema / properties / loan_interest_rate / title
```
Added value: +"Loan Interest Rate"
```
- addedInput schema / properties / loan_tenure_years / title
```
Added value: +"Loan Tenure Years"
```
- addedInput schema / properties / monthly_rent / title
```
Added value: +"Monthly Rent"
```
- addedInput schema / title
```
Added value: +"calculate_home_vs_rentArguments"
```
- addedOutput schema / title
```
Added value: +"calculate_home_vs_rentDictOutput"
```
Addedv0.4.2Jun 8, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent already knows this is a safe, non-mutating operation. The description adds a brief output summary ('yearly breakdown and break-even analysis') but no additional behavioral caveats or assumptions. There is no contradiction with 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.

Conciseness3/5

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

The opening is effective, and the use-when line is front-loaded. However, the description duplicates the entire input schema with a 9-line Args block, and the Returns line overlaps with the available output schema. It is structured and readable, but not every part earns its place.

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?

The description explains the decision context and outlines the output shape, while the schema covers all 9 arguments with defaults and units. It omits edge-rule details like how negative values or extreme assumptions are handled, but the output schema and full parameter documentation make it complete enough for confident invocation.

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?

All 9 parameters already have full schema descriptions with defaults, units, and meanings, so the Args list in the description is largely redundant. Where the description is terse, such as 'Loan tenure', the schema provides the needed clarification.

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 clear verb and resource: 'Compare buying vs renting financial outcome.' It immediately separates this from sibling tools like EMI, income tax, and GST calculators. The added 'Use when deciding between buying a home or renting' reinforces the exact decision it supports.

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 gives an explicit trigger condition: 'Use when deciding between buying a home or renting.' It does not mention alternatives or exclusion conditions, but among the sibling tools there is no other buy-vs-rent comparison, so the usage context is sufficiently clear.

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

Deploy Server