Curating the Tool Surface for a Financial Assistant

Tool access is product scope. An assistant that can call every model in the catalog has had its scope decided by the catalog — which is to say, by nobody who designed your product.

Worthune's MCP server exposes the whole catalog through three generic tools, and a wrapper around the REST API can expose any subset the same way. That neutrality is right for the platform and wrong as a default for your product, because every model an assistant can invoke is a promise your product is now making: that the assistant will route to it correctly, collect its inputs competently, phrase its sentinels honestly, and stand behind the answer. Curation is how those promises stay deliberate. This piece is the method.

Scope follows the product, not the catalog

Start from the questions your product exists to answer, not from the list of what is computable. A mortgage-focused product wants the refinance, extra-payment, points, PMI, and rent-versus-buy models — and arguably nothing else, because an assistant that will happily compute a startup's burn rate mid-mortgage-conversation is off its product's map even when the math is right. Scope is also a compliance surface: each model your assistant can reach is a model whose outputs your review process must have considered. A tool list is the rare place where less genuinely is more product, more focus, and less review burden at once.

The three-tool pattern with a filter

The implementation is simpler than the decision. Assistants using the MCP server directly can be constrained at the client or gateway layer to a permitted model list — the three generic tools stay, but run_model requests outside the list are declined by your wrapper before they reach the server. Assistants built on the REST API get the same effect by construction: your backend exposes exactly the calls it makes. Either way, the permitted list belongs in configuration, reviewed like the product decision it is, not scattered through prompt text that nobody audits.

Descriptions are routing infrastructure

When an assistant picks the wrong model, the failure usually traces to descriptions, not intelligence. The contract data helps — get_model_contract returns each model's inputs and constraints, which is strong routing signal — but your product layer knows things the catalog cannot: that your users say "should I pay extra on my loan" and mean the extra-payment model, that a question about "the 4 percent rule" belongs to the FIRE model's withdrawal-rate input, that ambiguous retirement questions in your product default to Roth-versus-traditional. Encode that mapping in the routing descriptions your assistant sees. The catalog describes what models compute; only you can describe what your users mean.

The refusal edge of the surface

Curation creates a new class of question: computable by the platform, excluded by your product. The honest response acknowledges both facts — the assistant does not pretend the computation is impossible, it says the product does not cover it, and where sensible it points at the general-purpose surface: the calculator on worthune.com, or the user's own advisor. The refusal-design guide (/writing/refusing-beats-guessing) distinguishes scope refusals from validation refusals and policy refusals; a curated tool surface is where scope refusals get their content. Write them when you write the allowlist — the two artifacts are one decision viewed from opposite sides.

• ✓Derive the allowlist from product questions, and review it like product scope.
• ✓Enforce it in configuration or a gateway, never only in prompt prose.
• ✓Write routing descriptions in your users' vocabulary, not the catalog's.
• ✓Stage models into the surface with per-model sentinel and dialogue checks.
• ✓Author the scope-refusal copy alongside the allowlist.

The audit story curation buys

A curated surface makes the trace data legible. When every tool call lands in a reviewed allowlist, the traces answer scope questions mechanically: which models the assistant used, how often, with what rejection rates — a bounded report a reviewer can actually read. An uncurated surface produces the same logs with none of the meaning, because nobody decided what the numbers should look like. Curation is not a restriction on the assistant; it is the difference between a tool surface your product operates and one it merely inherits.