FactLot

Loan amortization schedule

calc_amortization_schedule

Read-onlyIdempotent

Period-by-period schedule of a fixed-rate loan, monthly or quarterly: an optional interest-only period, then level payments on an amortization term that can run past maturity (balloon), with 30/360, actual/360, or actual/365 interest (the payment on a 30/360 basis). Rows are in cents that foot: interest is rounded each period, the final payment repays the whole balance, and the totals are the row sums. Deterministic: use this instead of doing the math yourself; cite formula calc.amortization_schedule@1 and the returned steps, and surface any warnings.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "principal": "<principal>",
      "rate_annual": "<rate_annual>",
      "term_months": "<term_months>",
      "amortization_months": "<amortization_months>"
    },
    "name": "calc_amortization_schedule"
  }
}

Input Schema

Name	Required	Description	Default
`day_count`	No	Interest day count: "30/360" (each period is 30 days a month: interest = balance × rate ÷ periods a year), "actual/360" or "actual/365" (balance × rate × actual days in the period ÷ 360 or 365; needs start_date). Under actual day counts the level payment is still computed on a 30/360 basis, as US commercial loans usually are, so the balloon absorbs the difference.	30/360
`principal`	Yes	Loan amount funded, USD.
`start_date`	No	Funding date, YYYY-MM-DD. Payment k falls k periods later on the same day of the month (clamped to month end); the first period runs from this date to the first payment date. Required for actual/360 and actual/365; optional for 30/360, where it only dates the rows.
`rate_annual`	Yes	Fixed nominal annual interest rate as a decimal, e.g. 0.065 for 6.5%.
`term_months`	Yes	Months from funding to maturity, when any remaining balance (the balloon) is repaid.
`payment_frequency`	No	Payment period: monthly (12 a year) or quarterly (4 a year). Term, amortization, and interest-only months must be whole periods.	monthly
`amortization_months`	Yes	Amortization period in months that sets the level payment after any interest-only period, e.g. 360 for a 30-year schedule; 0 means interest-only to maturity. Must be at least term_months − interest_only_months (a shorter schedule would repay the loan before maturity).
`interest_only_months`	No	Months of interest-only payments at the start of the loan; amortization over amortization_months begins after them. At most term_months.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered; the description goes well beyond by disclosing output invariants ('rows are in cents that foot,' interest rounded each period, final payment repays the whole balance, totals are row sums). It also explains the non-obvious interaction where the level payment is computed on 30/360 even under actual day counts, with the balloon absorbing the difference.

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?

Two blocks, front-loaded with the shape of the output and then the determinism directive — no filler. The first sentence is an over-stuffed fragment with nested parentheticals, and the phrase 'with 30/360, actual/360, or actual/365 interest (the payment on a 30/360 basis)' is grammatically broken, which costs it a point on readability.

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?

With no output schema, the description compensates by stating the row invariants, rounding behavior, and totals property — exactly what an agent needs to trust and present the result. Determinism, the citation format, and the warning-surfacing obligation round out the contract for a closed-world, idempotent calculation.

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 a 3 is the baseline and the schema already carries per-parameter detail. The description still adds cross-parameter meaning the schema states only in fragments: the interest-only-then-amortize sequencing, the amortization term running past maturity producing a balloon, and which day-count bases demand start_date.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb+resource: a 'period-by-period schedule of a fixed-rate loan,' and immediately enumerates the structural features it models (interest-only period, level payments, balloon, day-count bases). An agent can tell this is the amortization-schedule calculator rather than a general debt tool, though it never names a sibling (e.g. calc_debt_sizing or calc_prepayment_and_defeasance) to contrast against.

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 directive: 'use this instead of doing the math yourself,' plus a citation obligation (calc.amortization_schedule@1) and an instruction to surface warnings, which is genuine when-to-use guidance. It stops short of exclusions — it says nothing about when a different calc_* tool is the better call, so routing among the many siblings still requires inference.

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

All FactLot tools Inspect

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.