Ask any general-purpose AI what a borrower will pay on the Repayment Assistance Plan and you will get a number. It will be fluent, confident, formatted well, and unattached to any source. Sometimes it will be right.
That is the problem worth solving. Correct-ish student-loan math is now free and infinite. What is scarce, and what actually carries liability, is an answer somebody will stand behind: computed by code you can audit, at a stated rule version, recorded before it was handed over.
Finology Software’s engine is now callable directly by AI agents and applications. Three ways in, one of them free and keyless, and the full reference lives at finology.tech/agents.
Start free, with no key and no account
The fastest path is one command. It runs locally, needs no signup, and is MIT licensed:
npx -y @finology/mcp-serverOr point any MCP client at https://mcp.finology.tech/free and skip the process entirely. Either way you get four tools: compare every federal repayment plan a loan can actually elect, estimate a RAP payment, compare married-filing-jointly against separately, and ask the service what it is.
There is no math in the npm package. Every number it returns comes from the same engine that runs advisor client projections, so the free rung cannot drift from the paid one.
The tools volunteer the number nobody asked for
A calculator that answers exactly what it was asked is correct and useless. The interesting figure is almost always the one the question missed.
Ask the filing-status tool about a household with $60,000 of debt at 6.53%, a borrower earning $80,000 and a spouse earning $60,000. It does not just return two payments. It opens with this:
Filing status changes this borrower’s loan cost by $32,302.29 over the life of the loan.
Then it shows filing separately cuts the monthly payment by $700, and immediately says the part that should stop you: those figures are the loan side only. Separate filers commonly lose the student loan interest deduction and education credits, and that tax cost is frequently large enough to reverse the answer. The tool tells you it does not model it.
An agent relaying that gives its user a real decision instead of a confident half-answer. That is the whole design brief.
The keyed rungs: an answer that exists before you receive it
For products that need a traceable answer rather than an estimate, the keyed remote MCP server and the REST API do something the free rung does not.
Every answer is persisted with its rule version and a hash of its inputs before it is served. If it cannot be recorded, it is not served. That ordering is the entire point. An answer you can produce but cannot prove you produced is not an answer of record, and a system that logs after responding will always have a window where it answered and remembers nothing.
What is warranted, and what is not
Being precise about the boundary is more useful than claiming everything:
- Warranted, on the keyed rungs: the number is the engine’s output for the stated inputs at the stated rule version, and a record of it existed before you received it.
- Estimated, on every rung: tax on forgiven balances, computed at today’s brackets, and state tax unless a state is supplied.
- Not present: nothing in these answers is generated by a language model. The engine computes; the agent relays.
Everything served is for education, not individualised advice, and the API and MCP Terms of Service govern all three rungs.
Getting a key without talking to anyone
A sandbox key is issued instantly, by the call itself, with no human in the loop:
curl -X POST https://api.finology.tech/v1/keys/sandbox \
-H "Content-Type: application/json" \
-d '{"email":"you@example.com"}'| Tier | Calls / month | How |
|---|---|---|
| Sandbox | 100 | Instant, free, valid 30 days |
| Production | 100,000 | $499 a month, self-serve |
| Above that | 1,000,000+ | support@finology.tech |
There is no form, no call and no review at any tier. An agent can even collect its own production key: mint a sandbox key, hand the operator the prefilled payment link that comes back with it, and once payment clears call POST /v1/keys/claim with the sandbox key. The production key returns once. Nobody at Finology is involved, and nobody has to read a key out of an email.
Built to be found by machines
Discovery is served the way agents actually look: /llms.txt and /llms-full.txt, a server card at /.well-known/mcp/server-card.json, an RFC 9727 API catalog at /.well-known/api-catalog, agent skills, and /auth.md describing authentication. Both surfaces expose a health endpoint that reports the exact deployed commit, so you can tell which build answered you.
The servers are listed in the official MCP registry as tech.finology/student-loan and tech.finology/verified-engine.
Why this exists
Federal repayment changed on July 1, 2026. SAVE is gone, PAYE is closed to new enrollment, and RAP is the default for new borrowers. A model trained before that date will describe plans that no longer accept anyone, in complete sentences, without hedging.
When a wrong student-loan answer costs a borrower five figures, the question stops being whether the software is clever and becomes whether anyone will stand behind the number. That is what these surfaces are for.
Start with no key at finology.tech/agents. One command, four tools, and every number traceable to the engine that produced it.
Run a client-ready repayment plan in minutes
Every number sourced, every path compared. Model RAP, the new Standard, IBR, PAYE, ICR and PSLF side by side.
