The Model Context Protocol is how an assistant stops predicting numbers and starts computing them. Worthune's server exposes the Concordance-tested catalog and the household engine through a small set of deliberately generic tools, six of which need no credentials at all.
An AI assistant that answers financial questions needs a way to compute rather than recall, and the Model Context Protocol is the standard plumbing for exactly that. Worthune ships a public MCP server — listed in the official MCP registry as com.worthune/models — that any MCP-capable client can connect to with one URL and no credentials. This piece walks the setup and the keyless tools, then explains the design decision behind having so few of them.
The connection
The endpoint is https://worthune.com/api/mcp/mcp, speaking streamable HTTP. In Claude, it is added as a custom connector; other MCP clients take the same URL in their server configuration. There is no signup. What a key gates is the same boundary the REST API draws: three sample models answer for anyone, the rest of the catalog needs a paid key, and the household engine runs keyless for as long as you do not ask us to store anything. Once connected, the client discovers the server as worthune-models and lists its tools.
The tools that need no key
| Tool | What it does | When the assistant calls it |
|---|---|---|
| list_models | Returns every model name with its spec version | Once per session, or when routing a new question |
| get_model_contract | Returns a model's required inputs with domains, cross-field constraints, sentinel meanings, and the sourced constants it uses | Before the first run of any model |
| run_model | Executes a model and returns the full response envelope | Every time a user's question needs a number |
| verify_claim | Checks claims about a model's outputs against the engine — verified, violated, or out-of-scope, with the computed value as proof | Before stating a number the assistant derived or summarized itself |
| list_example_households | Returns twelve fictional households, each built to exercise a different part of the planning engine | When someone wants a worked shape rather than to describe their own finances from scratch |
| try_household_projection | Runs the full multi-year projection — income, required distributions, federal and state tax, the tax-grossed-up drawdown, net worth per year, optionally with a Monte Carlo — on a household document you pass in, and stores none of it | When the question is about a whole household rather than one calculation |
The intended sequence is discovery, contract, run. An assistant that calls run_model cold will learn the contract the hard way — every missing field named individually, every out-of-domain value rejected with its valid range — because the MCP surface is the same rejection-not-clamping engine as the REST API. The efficient loop reads the contract first. The household pair works the same way: list_example_households gives a valid document to start from, and try_household_projection returns the projection along with every simplification that fired and an evidence record whose hash reproduces on an identical document. Nothing is written down, so there is no account to create and nothing to delete afterwards.
run_model('employer-match', {salary: 120000, employeeContributionPct: 0.06, matchRate: 0.5, matchLimitPct: 0.06}) → ok: true, outputs: {employerMatch: 3600, totalAnnualSavings: 10800, …}, specVersion, assumptions, facts, record.sha256The envelope is identical to the REST API's: outputs plus spec version, echoed inputs, assumptions, triggered sentinels, the facts-registry constants with sources, and the SHA-256 record. The assistant's reply can cite the spec version and the constants because the tool result literally hands them over — the citation pattern the assistant-design guide develops is built on these fields.
Why a handful of generic tools and not one per model
The obvious alternative design is one tool per model, and it fails at both ends of scale. A tool per model — sixty-one of them today — bloats every request's tool schema, overwhelms tool selection, and goes stale the day the catalog grows. A handful of generic tools keeps the schema tiny, makes the catalog self-describing — list_models reflects whatever ships today — and puts the routing decision where it belongs: in the contract, which the assistant reads at runtime, rather than in tool definitions frozen at integration time. The catalog can add a model, and every connected assistant can use it the same hour, with no client-side change. The server has grown from four tools to fifteen since it launched, and not one of those additions was a model — they are new KINDS of question: create a household, sweep a book, narrate a decision.
Operational notes
- Add the endpoint once — the catalog updates server-side, and list_models always reflects it.
- Cache contracts per session, not forever — spec versions move, and the envelope tells you when.
- Treat rejections as conversation material — the field-level errors are written to be relayed to users.
- Log the record.sha256 with the conversation — the trace-audit guide builds on it.
- Show attribution where sample-model results reach end users — Powered by Worthune with a link, per the pricing page.
- Reach for try_household_projection before asking someone to sign up — it answers the whole question and keeps nothing.
The fit with everything else
The MCP server is a transport, not a different product. The models, the spec versions, the domains, the sentinels, and the envelopes are the same objects the REST API serves and the site renders — one engine, three surfaces. That identity is the integration guarantee: an answer computed in an assistant conversation, an answer computed by your backend, and an answer computed on worthune.com are the same answer, hash and all. The keyless household tools share their implementation with POST /api/v1/project for exactly that reason — the two were checked to return byte-identical evidence hashes for the same document, because a claim of one engine has to survive being tested.
Sources
- [1] Worthune API documentation (MCP section). https://worthune.com/docs
- [2] Model Context Protocol specification. https://modelcontextprotocol.io
- [3] Worthune writing: Designing an Assistant That Cites Its Spec Version. https://worthune.com/writing/assistant-that-cites