Skip to main content
Glama

PoliErgaleio

by com.poliergaleio
OverviewDiscussionsAdmin

compare_rent_vs_buy

Compares buying a home against renting using actual period mortgage payments and symmetric investment of whichever scenario has lower cash costs. Mortgage contributions stop after payoff; purchase/sale costs, maintenance, rent inflation and investment returns are included. Use only to compare buying a Cyprus home with renting over a stated horizon. Use financial facts stated or confirmed for this scenario. Do not carry values from another chat or scenario into the calculation until the user explicitly confirms the relevant values. Ask for any missing core term: property price, monthly rent, down payment and whether it is EUR or percent, mortgage rate, and mortgage term. If the deposit is given without a unit (for example, '20'), ask whether it means EUR or percent before interpreting, converting, deriving a loan amount, or calling this tool. Never infer the unit from context. Optional growth, inflation and return assumptions require user acceptance when not stated. Mortgage payments end at payoff, and cost differences are invested by the lower-cost side. After calculating, briefly summarize every material modelling default used (including defaults supplied in the call) and costs excluded or treated as zero; use structuredContent.assumptions for defaults and exclusions returned by the API.

Input Schema

NameRequiredDescriptionDefault
legalFeesNoEUR amount. Supply the actual value when applicable; use 0 only when confirmed to be zero.
stampDutyNoEUR amount. Supply the actual value when applicable; use 0 only when confirmed to be zero.
agencyFeesNoEUR amount. Supply the actual value when applicable; use 0 only when confirmed to be zero.
downPaymentYesDeposit amount. If the user gives no unit, ask whether it is EUR or a percentage before interpreting or calculating.
monthlyRentYesCurrent monthly rent, EUR.
transferFeesNoEUR amount. Supply the actual value when applicable; use 0 only when confirmed to be zero.
homeInsuranceNoAnnual home insurance, EUR.
propertyPriceYesEUR amount. Supply the actual value when applicable; use 0 only when confirmed to be zero.
rentFurnitureNoOne-off furnishing cost when renting, EUR.
agentCommissionNoEUR amount. Supply the actual value when applicable; use 0 only when confirmed to be zero.
maintenanceFixedNoAnnual maintenance in EUR when not using the percentage.
fittingsFurnitureNoOne-off furnishing cost when buying, EUR.
localAuthorityTaxNoAnnual local authority tax, EUR.
mortgageTermYearsYesMortgage term in years.
propertyTaxYearlyNoAnnual property tax, EUR.
transferTaxOnSaleNoAssumed transfer tax on exit, percent (default 0%).
commonAreaExpensesNoMonthly communal charges when renting, EUR.
rentYearlyIncreaseNoAssumed annual rent increase, percent (default 2).
analysisPeriodYearsNoComparison horizon in years (default 30).
salesCommissionRateNoAssumed selling commission on exit, percent (default 5%).
generalInflationRateNoAssumed annual inflation, percent (default 2).
investmentReturnRateNoAssumed annual investment return, percent (default 5).
mortgageInterestRateYesAnnual percentage value (e.g. 2.5 for 2.5%). Supply the actual rate unless the user accepts a stated modelling default.
maintenancePercentageNoAnnual maintenance as a percent of property value (model default 1%).
securityDepositMonthsNoDeposit expressed in months of rent.
downPaymentIsPercentageYesTrue only when the user explicitly confirms the deposit is a percentage; false only when they explicitly confirm it is EUR. Ask if unclear; never infer.
propertyAppreciationRateNoAssumed annual property appreciation, percent (default 3).
useMaintenancePercentageNoUse the percentage instead of the fixed maintenance figure (default true).

Output Schema

NameRequiredDescriptionDefault
seriesNo
assumptionsYes
totalCostBuyYes
breakevenYearYes
totalCostRentYes
buyInitialCashYes
rentInitialCashYes
buyNetWealthFinalYes
rentNetWealthFinalYes
opportunityCostGainYes
monthlyMortgagePaymentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses mortgage payoff behaviour, symmetric investment of cost differences, included cost categories, and requires a post-calculation summary of defaults and exclusions via structuredContent.assumptions. It stops short of stating whether the calculation is pure/read-only or persisted, which is a meaningful gap for a tool with save/update siblings.

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

Conciseness4/5

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

The length is warranted for a 28-parameter financial model, and purpose is front-loaded. There is some redundancy around the deposit-unit rule ('never infer the unit' repeated in different phrasing), but no sentence is idle.

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 28 parameters, no annotations, and an existing output schema, the description covers the decisions an agent must make before calling: required core terms, ambiguity handling, assumption acceptance, and disclosure of defaults/exclusions. Return-value explanation is correctly delegated to the output schema.

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 the schema already documents the 28 parameters; the description adds real value by mandating clarification of the downPayment unit, forbidding unit inference, and requiring acceptance of optional growth/inflation/return assumptions. That goes beyond the schema's per-field text and addresses the two most error-prone parameters.

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?

States a specific verb and resource ('compares buying a home against renting') and pins the scope to a Cyprus home over a stated horizon. The modelling stance (actual period mortgage payments, symmetric investment of the lower-cost side) distinguishes it from siblings like simulate_mortgage without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicitly restricts use to rent-vs-buy over a stated horizon, forbids carrying values from other chats, and enumerates the required core terms that must be asked for if missing. It also names the alternative behaviour for ambiguous deposit units and requires user acceptance for unstated assumptions.

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

All PoliErgaleio toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources