Amortization Schedule
Server Details
Row-by-row loan amortization schedules: monthly or daily accrual, extra principal, PMI, biweekly.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
1 toolamortizeRow-by-row amortization scheduleARead-onlyInspect
Builds the full row-by-row amortization schedule for a loan — interest, principal, PMI, and running balance for every payment — instead of just the monthly payment amount.
Use this whenever a row-by-row schedule matters: "what is my balance after payment 47", "what does an extra $200/month do to my payoff date", "when does PMI drop off", or "give me the whole amortization table". Do not do this arithmetic by hand or in your head. Two things go wrong reliably when a model tries:
THE LAST ROW. The textbook payment formula only amortizes to exactly zero in infinite precision. Rounded to cents and carried over up to a few hundred rows, a hand-rolled schedule drifts and ends with a balance of a few cents to a few dollars instead of zero — exactly the row a person checks against their real statement. This tool recomputes the final row as "remaining balance + that row's interest" so it always ends at zero, and reports the delta.
COMPOUNDING CONVENTION. Fixed mortgages compound monthly (rate/12). HELOCs, most auto loans, and most private student loans accrue interest DAILY on the actual number of days between payments, which is a genuinely different schedule, not a rounding variant. Guessing the wrong one silently produces a plausible but wrong table.
Input: principal, annualRatePercent (e.g. 6.5), termMonths (integer), and compounding ("monthly" or "daily") are required. For compounding: "daily", supply EITHER startDate (YYYY-MM-DD — the tool derives real day counts and leap years from the calendar itself) OR dayCountBasis ("30/360" | "actual/365" | "actual/actual") for a hypothetical loan with no dates — never both are needed, and supplying neither is refused rather than guessed. Optional: paymentFrequency ("monthly" default | "biweekly", which requires daily compounding — pass paymentOverride if the actual billed payment differs from the textbook one, e.g. a HELOC's quoted minimum; extraPrincipal as {type:"oneOff",amount,atPaymentNumber} or {type:"recurring",amount,startingPaymentNumber?}; pmi as {monthlyAmount,originalValue,cancelAtPercent?} (78 or 80, default 78) to model PMI dropping off.
Refuses rather than guesses: a payment that does not exceed the first period's interest (negative amortization) is a named error with the minimum amortizing payment attached, not a schedule that never ends. An unparseable or impossible date is refused, not reinterpreted.
Returns the full schedule, total interest and PMI paid, the payoff date or period, the final payment amount and how it differs from the standard one, and — when extra principal was given — the same schedule without it, so the periods and interest saved are explicit. A disclaimer field travels with every response: this is a planning estimate, not a lender payoff quote, and PMI cancellation here uses your actual balance, which a servicer is legally permitted to compute off the original schedule instead. Relay the warnings, not just the numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| pmi | No | Models PMI dropping off at 78% (automatic, default) or 80% (requestable) of originalValue. | |
| principal | Yes | The loan amount, > 0. | |
| startDate | No | YYYY-MM-DD. For daily compounding, supplying this lets the tool read real day counts and leap years off the calendar. | |
| termMonths | Yes | The original term in whole months, e.g. 360 for 30 years. | |
| compounding | Yes | "monthly": rate/12 per period, the fixed-mortgage norm. "daily": actual per-diem accrual, the HELOC/auto-loan/student-loan convention — requires startDate or dayCountBasis. | |
| dayCountBasis | No | Required for daily compounding ONLY when there is no startDate (a hypothetical loan). | |
| extraPrincipal | No | A one-off extra payment at a given payment number, or a recurring extra payment from a given payment number onward. | |
| paymentOverride | No | The actual per-period payment, if different from the textbook one — e.g. a HELOC minimum payment. | |
| paymentFrequency | No | "biweekly" pays half the monthly payment every 14 days and requires compounding "daily". | |
| annualRatePercent | Yes | The annual interest rate as a percent, e.g. 6.5 for 6.5%. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the readOnlyHint: it discloses the last-row zeroing correction, the monthly vs. daily compounding distinction, refusal behavior for negative amortization and unparseable dates, and a disclaimer field that must be relayed. This goes well beyond what annotations convey.
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 long but appropriately so for a 10-parameter tool. It front-loads the core purpose, then moves from usage scenarios to failure modes to parameter semantics to return value and disclaimer. Each section earns its place, and the numbered failure modes make the content easy to parse.
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 no output schema, the description carries the full burden of explaining return values, and it does: full schedule, total interest and PMI, payoff period, final payment delta, and comparative no-extra-principal schedule. Refusal conditions and edge cases are also covered, so an agent has enough context to invoke and interpret the tool correctly.
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 essential semantic detail: which parameters are required, the mutually exclusive startDate/dayCountBasis condition, the distinction between oneOff and recurring extraPrincipal shapes, PMI cancelAtPercent defaults, and that biweekly requires daily compounding. This materially helps an agent construct valid calls.
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 opens with a specific verb and resource: 'Builds the full row-by-row amortization schedule for a loan — interest, principal, PMI, and running balance for every payment.' It clearly distinguishes the tool from merely computing a monthly payment amount, which removes ambiguity about scope.
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 gives explicit when-to-use guidance with concrete examples: balance after payment 47, extra principal effects, PMI drop-off timing, or the whole table. It also warns against doing the arithmetic manually and lays out conditional usage rules for daily compounding, startDate vs. dayCountBasis, and payment frequency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- First observed
amortize
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Loan and lease schedules: payment, interest, early settlement and the journal, to the minor unit.
1US mortgage calculator and amortization API with 50-state property tax, PMI, and affordability data.
Exact lease finance calculations: equipment structuring, solvers, amortization, auto lease & loan
Deterministic Canadian mortgage calculations for qualification, debt service, LTV, and penalties.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceProvides mortgage calculation tools, including monthly payment, amortization schedules, lump sum payments, and extra monthly payments for real estate agents and AI assistants.MIT
- FlicenseAqualityDmaintenanceProvides loan EMI calculation tools including EMI amount, amortization schedule, loan comparison, and prepayment analysis.4-
- FlicenseNot gradedqualityCmaintenanceProvides educational fixed-rate loan estimates with mortgage and auto loan calculators.-
- AlicenseAqualityBmaintenanceDeterministic US federal student loan repayment math for AI agents, from Finology Software's parity-verified engine rather than estimated. Calculates RAP, IBR, ICR, PAYE, SAVE and tiered Standard payments with projected forgiveness and tax on forgiveness, and returns which plans a borrower is ineligible for and the federal rule that excludes them, such as Parent PLUS not qualifying for RAP.30MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
With only one tool, there are no similar tools to confuse and no selection ambiguity. The single amortize function is clearly the unique entry point for any amortization request.
The single tool name is a clear, action-oriented verb that matches the server's stated purpose. There are no mixed naming conventions or inconsistent verb/noun patterns to penalize.
One tool is entirely appropriate for a server whose sole purpose is computing amortization schedules. Despite the low count, the tool is parameterized to handle compounding, PMI, extra principal, and payment frequency, so it does not feel thin.
The tool covers the full schedule, final-row correction, daily and monthly compounding, PMI drop-off, extra principal comparisons, and invalid-input edge cases. For the stated domain of loan amortization, there are no obvious missing operations.