MCP or REST: Choosing a Transport for Assistant Math

Both transports return the identical envelope from the identical engine. Choosing between them is not a capability question — it is a question about where your control points live.

Teams building a financial assistant on Worthune face an early fork: connect the assistant to the MCP server directly, or put your own backend between the assistant and the REST API and expose your backend's functions as the tools. The fork matters less than it looks — the models, spec versions, domains, sentinels, and envelopes are identical either way — same fields, same values, same hash — and more than it looks, because the two architectures put the control points in different places. This piece maps the tradeoff so the choice is deliberate.

The direct MCP path

Connecting an MCP-capable client to com.worthune/models is the shortest path from zero to computed answers: a single endpoint and three tools, with nothing to build. The catalog is self-describing — list_models and get_model_contract mean the assistant discovers new models and current contracts at runtime — and the tool loop runs inside the assistant client, which handles retries, schemas, and result threading for you. What you give up is a place to stand between the assistant and the platform: allowlists, input policies, and trace capture have to live in client configuration or a gateway, because there is no code of yours in the request path.

The backend REST path

Wrapping the REST API puts your server in the loop: the assistant calls your functions, your functions call /api/v1/models/{model}, and everything you own about the interaction happens in between. Tool curation becomes literal — your backend exposes exactly the operations you wrote. Trace storage is a database write in code you control. You can enrich calls with product context (a saved profile supplying defaults the user confirmed), enforce your own validation messages in your own voice, and cache identical runs keyed on model, version, and inputs. The cost is that you now own a tool loop: schemas, error threading, retry behavior, and the ongoing work of keeping your wrapper honest as the catalog grows — the self-describing property does not reach through code you froze.

The hybrid that usually wins

Framed as a fork, the choice reads as either-or. Framed as a lifecycle, it resolves: direct MCP is the evaluation and prototyping transport, and the backend path is the production transport for products with real audit obligations. Prototype against the MCP server to learn the contracts, the sentinel phrasings, and the routing behavior with zero build cost. When the product's obligations arrive — allowlists that must be enforced, traces that must be stored, context that must be injected — move the tool loop into your backend, keeping the MCP connection for internal tooling and exploration, where its zero-maintenance freshness stays valuable. The envelope's sameness across transports is what makes the migration boring: nothing about the answers changes, only who is standing next to them.

Decision shortcuts

• ✓Evaluating the catalog or building an internal tool — direct MCP, today.
• ✓Shipping numbers users act on, with trace obligations — backend REST, with the tool loop in your code.
• ✓Need product context in the calls — backend, it is the only place context lives natively.
• ✓Team has no backend at all — MCP plus a gateway for the allowlist, and revisit when obligations grow.
• ✓Unsure — prototype on MCP, and let the first real audit requirement make the call.

What not to decide with

Two considerations that feel decisive are not. Latency: both transports terminate at the same engine, and the deterministic computation is not where an assistant conversation spends its time. And capability: no model, sentinel, constant, or envelope field is exclusive to either path — the platform maintains one surface, transported two ways. Any argument for one path that rests on the answers being different is wrong about the platform; the honest arguments are all about ownership, and ownership is a product decision.