I turned my calculator site into an MCP server so AI assistants stop guessing at math

Rhein — Sat, 22 Aug 2026 08:29:07 +0000

Ask a language model to compute 2 + 3 * sqrt(16) and it will usually get it right. Ask it for 1,000,000 seconds in days, or a compound-interest figure over 30 years, and it will answer with total confidence — and sometimes be quietly wrong. It's predicting the next token, not running a calculator.

I already had a calculator. A whole site of them — 70-odd converters and calculators I'd built over the past year. So instead of writing another chatbot wrapper, I did the obvious thing: I let the AI call the real tools directly, over MCP.

Here's how that went, including the parts that didn't work.

MCP in one paragraph

The Model Context Protocol is a standard way for an AI assistant to discover and call external tools. The assistant asks your server "what can you do?", gets back a list of typed tools, and calls them with arguments — you run the actual code and hand back a real result. Claude speaks it, and a growing list of other clients do too. Think of it as giving the model hands instead of asking it to remember everything.

The constraint that shaped everything

My site is static, served by a single Cloudflare Worker. There's no backend to spin up, no container, no database. So the MCP server couldn't be a separate service — it had to live inside the Worker I already deploy.

That pushed me toward the simplest possible design: JSON-RPC 2.0 over plain HTTP, completely stateless. No sessions, no auth, no storage. A POST is a tool call, a GET returns server info. The whole thing is a few hundred lines with zero dependencies, sharing the same calculation code the website's buttons already run.

POST /mcp
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call",
  "params": { "name": "scientific_calculator",
              "arguments": { "expression": "2 + 3 * sqrt(16)" } } }

{ "jsonrpc": "2.0", "id": 1, "result": {
    "expression": "2 + 3 * sqrt(16)", "result": 14 } }

Decision 1: every result links back to a real page

The single design choice I care about most: every tool response includes a source_url pointing at the human page for that tool.

{ "expression": "2 + 3 * sqrt(16)", "result": 14,
  "provider": "SmartTools",
  "source_url": "https://smart-tools.xyz/en/scientific-calculator" }

Two reasons. The honest one: if an assistant tells a user "your monthly payment is X," the user should be able to click through and see the formula, not take a black box on faith. The selfish one: it's a citation trail back to the site. (The link even localises — pass locale: "de" and you get the German page.)

Decision 2: no `eval`, ever

The scientific calculator evaluates arbitrary expressions — sin(pi/6), 5!, log(1000), nested parentheses, operator precedence. The lazy way is eval(). In code that runs inside the same Worker that serves the whole site, that's a door I'm not opening.

So it's a hand-rolled recursive-descent parser. Boring, safe, and it forced me to make the grammar decisions explicit. One that trips people up:

-2^2   // -4, not 4

Unary minus binds looser than exponentiation, so this reads as -(2^2) — the mathematical convention, and the same answer a TI calculator gives. Factorial binds tighter than ^; % is floored modulo, not "percent". None of that is guessed at runtime; it's all in the parser.

The parser is byte-for-byte identical between the website widget and the MCP tool, and a test asserts they never drift apart.

What I couldn't expose (the honest ceiling)

Not everything made it. The site has image converters, a PDF-to-image tool, an Excel viewer — and none of them can be MCP tools. They rely on a browser canvas and WASM running on the user's own machine; there's nothing to run in a stateless Worker. About ten tools stay browser-only. Anything that's pure calculation or text made the cut — 73 tools so far.

I'd rather say that plainly than pretend the server does more than it does.

Try it

No key, no sign-up, nothing stored — it reads your input, computes, replies.

claude mcp add --transport http smart-tools https://smart-tools.xyz/mcp

Or point any MCP client at the endpoint directly:

{ "mcpServers": {
    "smart-tools": { "type": "http", "url": "https://smart-tools.xyz/mcp" } } }

There's a fuller write-up (and the tool list) at smart-tools.xyz/en/mcp.

What I'd still like to figure out

The thing I keep going back and forth on: how much a general-purpose calculator tool actually helps a modern model, versus just letting it reason. For arithmetic it clearly reasons fine now. For long unit conversions, financial formulas, and anything where being exactly right matters, handing it a deterministic tool still feels safer than trusting a token predictor. If you've measured this properly, I'd genuinely like to hear it.

It's a side project, it's free, and I built it because the alternative was trusting an LLM's mental math. If you try it and something's wrong, tell me — that's the whole point of a tool that shows its work.

I built 79 browser tools that never upload your data — here's why client-side matters

Rhein — Fri, 31 Jul 2026 13:27:31 +0000

Every developer has hit this: you need to resize an image, decode a JWT, or format a messy JSON blob. So you search "online [thing]", land on some tool, and… it wants to upload your file to a server first.

For a random stock photo, fine. For a customer CSV, a production JWT, or a screenshot of an internal dashboard? You just handed a stranger's server your data.

I got tired of that, so I built SmartTools — 79 small, single-purpose tools that do all the work in your browser. Nothing is uploaded. Ever.

The rule: the data never leaves the tab

Open any tool, open your browser's Network tab, and use it. You'll see no upload request. That's the whole design constraint:

Image tools (resize, crop, compress, convert JPG/PNG/WebP, favicon, colour-palette extraction) run on a <canvas>. The file is read with FileReader, drawn, re-encoded, and handed back — the bytes never touch a network.
Text & dev tools (JSON formatter, Base64, JWT decode, hash, regex tester, URL encode, cron parser, UUID, number-base) are plain JavaScript on the string you paste.
Calculators (finance, health, math) are just arithmetic on your device.

Because there's no server round-trip, the tools also work offline after first load, and there are no accounts, no rate limits, and no "upgrade to process files over 5 MB".

Why this is more than a privacy nicety

A few things fall out of the client-side approach that genuinely surprised me:

The JSON formatter uses your browser's own JSON.parse. If it says your document is valid, every runtime built on the same spec parses it too — no lenient validator quietly accepting a trailing comma that breaks in prod.
The UUID generator uses crypto.getRandomValues, not Math.random. That distinction matters the moment a UUID becomes a token instead of a row id — predictable randomness is a real breach class.
Image conversion strips EXIF/GPS as a side effect of redrawing on a canvas. Handy when you're about to post a phone photo somewhere public.

None of that needs a backend. It's all sitting in the browser already; most "online tools" just don't use it.

The honest trade-offs

Client-side isn't free of limits:

Big images hit browser memory/canvas caps (a 50 MP photo is ~200 MB decoded before you even encode).

The honest trade-offs

Client-side isn't free of limits:

Big images hit browser memory/canvas caps (a 50 MP photo is ~200 MB decoded before you even encode).
There's no server to do heavy lifting like OCR or real video transcoding.
You're trusting the page's JavaScript — but that's inspectable, and "no network request" is verifiable in a way "we delete your file after an hour" never is.

Free and multilingual

79 tools, 7 languages (EN/DE/ES/FR/IT/NL/UK), no sign-up. Every calculator's maths is cross-checked against an independent implementation before it ships, because a calculator that's confidently wrong is worse than none.

👉 smart-tools.xyz

I'd genuinely like feedback — especially: which tool would you want next? I pick what to build from real demand, so tell me what you keep googling.

DEV Community: Rhein

I turned my calculator site into an MCP server so AI assistants stop guessing at math

MCP in one paragraph

The constraint that shaped everything

Decision 1: every result links back to a real page

Decision 2: no eval, ever

What I couldn't expose (the honest ceiling)

Try it

What I'd still like to figure out

I built 79 browser tools that never upload your data — here's why client-side matters

The rule: the data never leaves the tab

Why this is more than a privacy nicety

The honest trade-offs

The honest trade-offs

Free and multilingual

Decision 2: no `eval`, ever