Guides / Building software with AI agents

How we gave every app an MCP interface, and what an AI assistant can do with it

Why each of our apps has a Model Context Protocol server, how one is made from the app's own functions, a shielding question worked through it, and the rules.

Product help

By Steven Michael Barber · Published October 29, 2026 · Updated November 3, 2026 · 7 min read

Every app we make now has a second front door. Next to the web page, the store app or the spreadsheet there is a small program an AI assistant can talk to, which offers the app's own arithmetic and rules as a set of named tools. The door is the Model Context Protocol, MCP, an open standard for connecting assistants to software. This guide explains why we built it, how a server is made from an app, what an assistant can and cannot do through it, and the rules every server follows. The public servers, one page each, are listed at Connect an AI assistant; this page is for a reader deciding whether to connect one.

Why an assistant needs a door of its own

An assistant answering a calculation from memory may choose the wrong constant or miss a model assumption. Our calculator applies a documented formula with published constants. MCP lets an assistant use that calculation and return its assumptions and limitations with the result. It makes the arithmetic reproducible; it does not establish the measured conditions around a real source.

MCP closes that gap. An MCP server describes its tools in a machine-readable list: a name, a description written for the model, and a schema for the arguments. The client, which is the assistant's host program such as Claude Code or Claude Desktop, shows that list to the model. When the model decides a tool fits the question, the client calls the server, the server runs the real function and returns the result, and the model writes the answer from the result rather than from memory. The assistant does the understanding and the explaining; the app does the numbers.

We had two reasons to want this for every app and not just the calculators. The first is our own development: agents writing guides, tests and worked examples can check figures against the product functions. The second is the reader. Anyone can connect an assistant to the public servers and calculate a bookkeeping report, a cash-flow forecast or a dose-rate estimate from inputs they supply. These servers do not connect to a customer's stored books or other account data.

What we built, in one afternoon

The repository holds twenty-one apps, and we did not want twenty-one copies of a protocol handler. We wrote one shared package, about four hundred lines, with no third-party dependency. It knows the handful of protocol messages a server must answer: the handshake, the tool list, a tool call, and the optional lists of resources and prompts. It checks every argument against the tool's schema before the tool runs and names the exact field that is wrong, so the model can correct itself. It carries results back as JSON text the model can read and as structured data a program can use. It has two transports: standard input and output, which is how a desktop client starts a server as a child process, and a stateless HTTP endpoint for the public servers and one internal tool.

Each app then got a folder with three files. The server file names the tools and maps each one onto a function the app already had. The entry file is three lines that start the server on standard input and output. The test file calls every tool through the same code path a client would use and compares the results with the app's own functions. A registry at the root of the repository lists every server, and a script reads that registry, builds each server, writes its tool table into the app's guide, and writes the project configuration file that Claude Code reads so that a session in the repository finds all the servers without any setup. A test fails if a guide and its server disagree, so the documentation cannot drift from the code.

The tools wrap only pure functions: code that takes values and returns values, with no database, no network and no account. That was a deliberate line. A tool that reads a customer's stored ledger would need sign-in, permissions and an audit trail, which the web apps already have and the servers do not need to duplicate. What the servers offer is the reasoning the apps contain: the double-entry check, the forecast, the margin calculation, the compliance deadline, the standings table. Where an app's logic needs a browser or a model call, such as the accessibility scanner's page crawl, the server leaves it out and the guide says so.

Worked example: a shielding question through the calculators server

A radiation safety officer connected to the calculators server asks their assistant: "What does a 100 mCi Cs-137 source read at 2 m, and how much lead brings it under 2 mR/h?" The model reads the tool list and picks gamma_dose_rate. It fills the arguments from the question: solve for the dose rate, isotope cs-137, activity 100 in mCi, distance 2 in m. The server converts the activity to curies, takes the published specific gamma-ray constant for cesium-137, 0.33 R·m²/(Ci·h), and applies the inverse-square formula:

Ẋ = Γ · A / d² = 0.33 × 0.1 / 2² = 0.00825 R/h = 8.25 mR/h

The result comes back with the unit the question used, the constant that was applied, the page on our site that reproduces it, and the same educational-estimate notice every radiation page carries. The model then calls the tool a second time, now solving for thickness with a target of 2 mR/h and lead as the material. The server works out the transmission needed, 2 divided by 8.25, about 0.24, and converts it to a thickness with the published tenth-value layer for cesium-137 in lead:

Had the officer typed the distance in feet, the schema check would have accepted ft as a unit id; had they typed a unit the calculator does not know, the server would have answered with the list of units it does, and the model would have asked or corrected. The reader can click through to the page and repeat the arithmetic by hand. These remain model estimates: real source geometry, shielding, scatter and instrument response affect the measured dose rate.

The public calculation servers

• Pure and stateless calculations. These tools read no customer database and call no other service to compute a result. A server run from the repository stays on the user's machine. The public servers answer over HTTPS without retaining calculation inputs; hosting request metadata and abuse controls are described in our privacy policy.
• Honest names and hints. Tool names are plain verbs and nouns. Public calculation tools are marked read-only and idempotent, which lets the client recognize that repeated calls do not change customer records. The client's own permission settings still control when it asks before a call.
• Errors the model can read. A wrong argument names the field. A rule the app enforces, such as a resale value above the purchase price, comes back as a readable message, not a crash.
• The app's own disclaimers travel with the result. Radiation results carry the educational-estimate notice; bookkeeping results say they are not tax advice; the compliance tools say the license conditions govern.
• Documentation is generated. The tool table in each guide is written by a script from the running server and checked by a test, so what the guide says a tool takes is what the tool takes.

Connecting one

The public servers need no account and no install. Each one's page under Connect an AI assistant gives its address, its tools and what to do if a call fails. In Claude on the web or the desktop app, add a custom connector with that address; Claude Code and Codex take one command; any other MCP client uses the address over Streamable HTTP.

The other servers run from a copy of the repository: a Claude Code session opened in the folder lists them and asks before using them, and other clients take a one-line entry naming the entry file. Each app's guide carries the exact lines, and the master guide covers the protocol, the shared package and how we test the servers. One internal operations tool's server answers over HTTP behind an API key the owner issues.

The internal operations server has tools that can act on the world, marks them accordingly and defaults to a dry run. It is separate from the public calculation servers and is not covered by their connection instructions. If a public product later offers signed-in operations, its documentation will identify the account required and what each tool can change.