Skip to main content
Glama

Project Gumball

Build a loan amortization schedule (Amortization Schedule)

amortize_schedule
Read-only

Returns the full row-by-row schedule: per-period interest, scheduled principal, any extra principal, PMI, payment and running balance. Handles monthly or daily accrual (daily needs a start date, so leap years follow from the calendar rather than an assumption), biweekly payments, one-off or recurring extra principal, and PMI termination under the Homeowners Protection Act at 78% or 80% of the ORIGINAL value — plus the midpoint trigger that ends PMI regardless of balance. The final payment differs from every other one and is reported as such. Refuses a payment that cannot amortize the balance rather than producing a schedule that never ends. Not financial advice.

WHY DELEGATE THIS: A model gets the payment formula roughly right and then drifts: over 360 rows the principal/interest split accumulates rounding error, and the final payment — the one row people actually check against a statement — is almost always wrong. It also cannot reliably answer what an extra $200 a month does to the payoff date. Compounding is a parameter rather than an assumption, because monthly and daily accrual produce genuinely different schedules and the caller knows which loan they have.

Owned by Amortization Schedule at https://amortize.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
principalYesLoan amount in dollars.
startDateNoISO YYYY-MM-DD. Required for daily accrual unless dayCountBasis is given.
termMonthsYesTerm in months, e.g. 360 for thirty years.
compoundingNoMonthly (rate/12) is the US fixed-mortgage norm. Daily is simple daily accrual.
dayCountBasisNo
paymentFrequencyNo
annualRatePercentYesAnnual rate as a percentage, e.g. 6.5 — not 0.065.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

The annotations only indicate readOnly and openWorld hints, so the description carries the behavioral burden. It discloses important behavior such as the final payment differing from others, refusing non-amortizing payments, PMI termination rules, daily accrual requiring a start date, and the 'not financial advice' caveat. Nothing here contradicts the readOnlyHint.

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 longer than average but well-structured with a lead summary, capability list, delegation rationale, and ownership note. Each section earns its place, though the ownership/URL paragraph is somewhat supplementary and could be trimmed without losing invocation guidance.

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?

With no output schema, the description does a good job listing return fields and explaining complex behaviors like PMI termination and failing gracefully on non-amortizing payments. It is slightly incomplete regarding how to specify extra principal and PMI inputs, since those capabilities are mentioned but not mapped to schema parameters.

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 coverage is 71%, and the schema already documents most parameters such as annualRatePercent format and compounding options. The description adds some rationale for compounding being a parameter and notes the daily accrual start-date requirement, but it does not deeply document the remaining parameters. Baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Returns the full row-by-row schedule' and lists the exact output fields. It clearly identifies this as a loan amortization schedule builder, and the detailed capabilities make it distinguishable from the unrelated sibling tools.

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?

The 'WHY DELEGATE THIS' section gives strong context for when to use the tool: when model drift on long schedules, final-payment accuracy, or extra-principal impact matter. It also offers a direct alternative URL, but does not explicitly state when not to use this tool versus a sibling.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources