TrueCalci

mortgage_piti

Calculate US monthly mortgage payment (PITI: Principal, Interest, Property Tax, Insurance & PMI) and 30-year amortization schedule.

Input Schema

TableJSON Schema

Name	Required	Description
`homePrice`	Yes	Purchase price of the home in currency units (e.g. 450000)
`tenureYears`	No	Loan duration in years (e.g. 15, 20, 30)
`interestRate`	Yes	Annual interest rate in % (e.g. 6.8)
`loanTermYears`	No	Loan duration in years (standard US alias for tenureYears)
`annualPmiPercent`	No	Annual PMI % if down payment < 20%
`downPaymentPercent`	No	Down payment percentage (e.g. 20 for 20%)
`annualHomeInsurance`	No	Annual hazard insurance premium
`propertyTaxRatePercent`	No	Annual property tax rate %

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 5, 2026

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden, but it only states what is calculated. It does not disclose that tenureYears/loanTermYears can change the amortization term, that PMI applies conditionally when down payment is below 20%, or other calculation assumptions. The claim of a '30-year' schedule also conflicts with the schema's variable loan term parameters.

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 description is a single sentence with no filler, and the core purpose is front-loaded. However, given the tool's parameter complexity, it is slightly too terse to serve as a complete standalone guide, keeping it from a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is an 8-parameter calculation tool with no output schema and no annotations, but the description only provides a one-line summary. Missing details include variable term handling, conditional PMI behavior, tax/insurance calculation basis, and what the amortization schedule contains, making it insufficient for confident invocation in edge cases.

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?

Schema description coverage is 100%, so the schema already documents all parameter meanings. The description adds only a high-level PITI framing and output type, which maps loosely to parameters but does not clarify relationships like tenureYears vs loanTermYears or how taxes/insurance are applied.

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 the action ('Calculate') and the resource ('US monthly mortgage payment (PITI)'), then names the concrete output ('30-year amortization schedule'). This distinguishes it from siblings like home_loan_emi by emphasizing the US/PITI scope.

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

Usage Guidelines3/5

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

The description gives useful domain context (US mortgage, PITI) that implies when it should be used, but it never explicitly states when to prefer this tool over alternatives or when not to use it. The intended usage is inferable, not spelled out.

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

All TrueCalci tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0

Disambiguation4/5

Most tools are clearly separated by domain and target calculation, such as rocket_deltav versus projectile_motion or black_scholes versus compound_wealth. A few pairs like home_loan_emi/mortgage_piti and contractor_parity/billable_floor could be initially confused, but the descriptions resolve the intended use cases.

Naming Consistency4/5

All tool names are lowercase snake_case and generally follow a topic-plus-suffix pattern, which is readable and consistent. The pattern is not a strict verb_noun convention, and acronym-heavy names like feie_nomad_tracker, scorp_optimizer, and casio_991_solve introduce stylistic variance.

Tool Count3/5

At exactly 25 tools, this is at the heavy but still usable end of the scale. The broad spread across tax, finance, engineering, physics, math, and cloud cost makes the server feel more like several domain calculators merged into one service.

Completeness4/5

Each tool is a self-contained calculation with no missing follow-up operations, so there are no obvious dead ends for the workflows it targets. The main gaps are minor adjacent calculators—such as NPV, depreciation, or broader statistical inference—that agents could work around or obtain elsewhere.

Resources

Need Help?