Embed Widgets vs. Backend API vs. MCP

The comparison is between integration patterns, not vendor products. The choice depends on where the math needs to appear and who is asking for it.

There are three ways verified financial math generally arrives on a product surface. A backend API call fetches numbers a server-rendered page or app displays. An embedded widget renders a full calculator on a page from a single script include. An MCP server exposes the same math to an AI assistant that computes rather than guesses. Each pattern serves a different surface, and the sensible choice is more often obvious from the surface than from a feature comparison.

Backend API

The backend API pattern fits products that already own their UI, their form validation, their branding, and their user-flow logic. The caller sends inputs, receives an envelope, and displays whatever it wants of the response. The pattern demands the most from the caller's engineering team — form design, error handling, layout — and offers the most control in return. Most wealthtech, insurtech, and fintech products with an opinion about their own UI end up on this pattern for at least some of its calculators.

The backend API pattern also fits AI product surfaces that need deterministic answers without adopting the MCP protocol. A chat product with a bespoke agent architecture can call the API from a tool-use step and cite the returned envelope in the assistant's reply, achieving the same computes-not-guesses behavior MCP produces without adopting MCP itself. The article that develops this pattern is the batch-1 Approximation vs. Computation piece.

Embedded widgets

The embedded-widget pattern fits products that need a calculator on a page without owning the UI for it. Marketing sites, editorial articles, help centers, and content-CMS environments where the calculator is one page among many are all candidates. A single script tag renders a full calculator, handles its own validation, and shows the result inline. The caller does not touch the arithmetic and does not build the form; the tradeoff is less control over presentation and branding.

Worthune ships this pattern today: a data-worthune-embed div plus one script tag (worthune.com/embed.js) renders a verified calculator in an iframe, with optional data-input prefill attributes. The frame carries its own verification link, disclaimer, and attribution badge, and embeds are free with attribution — the pricing page's terms apply to the badge, not to usage. The batch-1 Six Answers piece describes the surface a widget-shaped experience should expose regardless of who builds the wrapper.

MCP server

The MCP pattern fits products where an AI assistant is the surface the user interacts with. Model Context Protocol is an open specification for exposing tools to language models; an MCP-capable assistant can discover, read the contract of, and invoke tools without a bespoke integration on each side. A verified-math MCP server makes financial computation available to any MCP-capable assistant, which computes deterministically and cites the spec version in its reply.

The MCP pattern is the newest of the three, but the protocol is now broadly adopted across major assistant runtimes; the pattern rewards teams building assistant-first products. The pattern is not a replacement for the backend API pattern; it is a companion to it. A team building both a web product and an assistant will typically use the API for the web product and the MCP server for the assistant, from the same underlying model catalog.

How to choose

Start with the surface. If the surface is an assistant, MCP is the pattern; the alternative is a bespoke tool-use integration against the same API, which is more work for the same behavior. If the surface is a content page, an embedded widget is the pattern; the alternative is a thin caller-built wrapper on the API, which is more control at a small cost of extra work. If the surface is a full product experience with branding and flow logic, the backend API is the pattern; the alternatives require the caller to fight the vendor's UI, which is never a good use of engineering time.

Most callers end up using two of the three. A product with a web app and a marketing site uses the API for the app and either a widget or a thin API-wrapper for the site. A product with a web app and an assistant uses the API for the app and MCP for the assistant. The three patterns are not mutually exclusive; the same catalog serves them all, and the answers are the same envelope regardless of the pattern that requested them.

“Pick the pattern that matches the surface. The math is the same either way.”

The dimension that does not vary

Regardless of pattern, the response envelope is the same. API and MCP calls return the same envelope — model, specVersion, echoed inputs, outputs, sentinels, assumptions, facts, a SHA-256 record, and a disclaimer — and storing it preserves the same audit properties regardless of which pattern requested it. The embed surface displays its verification link and disclaimer inside the frame rather than handing the host page an envelope to store. A UI can migrate from widget to API to MCP over time without changing what it stores or what it can prove about a past answer. Pattern-level portability across the same catalog is the property that makes the choice reversible.

What the three patterns share

All three patterns share three properties beyond the envelope. First, validation-first behavior: out-of-domain inputs are rejected rather than clamped, and the caller receives a specific error rather than a defensible-looking approximation. Second, no optional inputs: every model requires every input the spec names, and the response echoes them back for storage. Third, the disclaimer field, present on every response, which the caller displays somewhere on the surface as part of the good-faith accuracy posture. These properties are not pattern-specific; they are catalog-level, and they hold regardless of whether the caller reached the model through an API call, an embedded widget, or an MCP tool invocation.

When to defer the choice

Callers who are unsure which pattern fits a specific surface can defer the choice by starting with the API pattern. The API is the most general of the three; it supports the other two by construction. A UI that starts on the API can later be re-wrapped as a widget-shaped experience by any team that wants to expose it that way; the same API is what an MCP server invokes under the hood. The reverse migrations are also possible but require more work. When in doubt, start on the API and let the surface tell the team which pattern to migrate toward.