Is Amortization Schedule MCP server safe?
Probably. Read the findings first.
Use with care. Some checks failed or could not be verified.
Public scan report
scanner v0.1.9 · 2026-09-20 · same rubric, same numbers if you re-run it
1 low
- –Code scanremote-only server, no package to scann/a
- Live reliabilityremote reachable in 1240ms20/20
- Tool poisoning1 tool descriptions checked13/15
- Auth qualityopen endpoint, read-only tools10/15
- Maintenancerepository not readable: repo not found3/15
- Maintainer identityverified namespace with website, no repo4/10
Findings (1)
- lowUnusually long tool description (over 2,000 characters)
poison.long-descriptiontool amortize: …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: 1. 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. 2. 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.…
Overall 67/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON