The Model Context Protocol is how an assistant stops predicting numbers and starts computing them. Worthune's server exposes the entire verified catalog through three deliberately generic tools.
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 three tools, then explains the design decision behind having only three.
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 API key and no signup — the MCP surface follows the same access model as the REST API, free with attribution, with the same fair-use guideline. Once connected, the client discovers the server as worthune-models and lists its three tools.
The three tools
| 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 |
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: get_model_contract returns the input domains an assistant needs to collect the right values from the user, the constraint notes it should surface as assumptions, and the sentinel meanings it will need to phrase honest answers. For models where the assistant wants the full reasoning, the tool takes an include_spec flag that returns the entire specification markdown — formulas, assumptions, exclusions, and known issues — inline.
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 three 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 — forty-seven of them today — bloats every request's tool schema, overwhelms tool selection, and goes stale the day the catalog grows. Three generic tools keep the schema tiny, make the catalog self-describing — list_models reflects whatever ships today — and put 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.
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 MCP results reach end users — Powered by Worthune with a link, per the pricing page.
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, whenever the model, version, and inputs match. Everything else in this pillar — traces, tool curation, evaluation — builds on that sameness.
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