Building in Public | Building the Calculator Before the App

TL;DR Wondering how I could make my knitting calculator available to AI assistants led me back to an approach I already wanted to take: building the calculation engine as a standalone library, with a command-line tool as its first interface. The same library can later power an iOS app, website, public API, or MCP-backed plugin.

I am positively itching to start building this knitting app.

Lately, I've been thinking that as soon as I get a spare moment I want to create a Git repository and start coding the iOS app. But today, instead of thinking about the app itself, I found myself thinking about "meeting users where they are." The phrase came up at work, and it stuck with me. I started thinking: What if, instead of seeking out a knitting calculator, some knitters are asking AI assistants to calculate evenly spaced increases or decreases?

Could an assistant use the calculator I'm planning to build? And if it did, could it give me credit? What would I need to create to make that possible? Those questions led me through APIs, MCP servers, and skills.

Oddly enough, all of that research led me back to the approach I was already planning to take, and reinforced why it mattered.

The command-line idea

Earlier this year, I finished reading Mobile System Design by Tjeerd in ’t Veen. In it, he discusses the importance of keeping an application’s business logic separate from its user interface. The principle itself was not new to me; I was already familiar with it and a big fan of it.

However, in t' Veen suggests what I think is an ingenious way to enforce that separation: make the business logic usable from the command line! A command-line tool has no buttons, navigation, animations, or screen layout. It accepts text input and produces text output. If the essential behaviour of an application works there, it cannot quietly depend on a particular graphical interface.

I love this idea. I had planned to approach my project this way ever since I read in t'Veen's suggestion, especially because I hope to create an iPad app as well as an iPhone app. The calculator would exist independently from either interface. I could give it a starting stitch count, a target stitch count, and a few other details, and it would produce a correct set of knitting instructions, but potentially displayed in a very different UI.

When I started thinking about AI assistants, I realised these were not two separate ideas. The boundary that prevents the calculation code from becoming tangled with an iPhone interface is the same boundary that allows a website, an API, or an AI assistant to use it.

A calculator for AI assistants

A normal web calculator has a graphical user interface. A knitter enters a starting stitch count and a target stitch count, presses a button, and receives instructions. That works well when a person visits the website directly.

But what if the knitter asks ChatGPT or Claude how to increase evenly from 52 stitches to 60 stitches in the round?

An AI assistant could attempt the calculation itself, and it might produce the correct answer. But that's not the same as using my tested calculator: it wouldn't necessarily follow the same algorithm or provide my explanation. If I want an assistant to use my calculator, I need to give it a way to communicate with my calculator directly.

That is what an API provides. An API is an interface intended for software rather than people. Instead of filling in a form, an AI assistant could send the stitch counts directly to the calculator’s public API. It could send something like:

{
  "startingStitches": 84,
  "endingStitches": 96
}

The API could return the result as structured data, along with the calculator’s name and a link to a human-readable explanation.

To be clear, simply making a public API available is not enough for an AI assistant to find and use it (I will go into that in the next section). However, even with the necessary integration, I could not guarantee that every assistant would use my calculator or give it credit. The assistant ultimately controls the answer shown to its user. What I could do is make my calculation engine available, return clear attribution with its results, and give assistants an alternative to recreating the logic themselves.

Where MCP and skills fit

MCP stands for Model Context Protocol. It provides a standard way for an AI application to connect to an external server and use the tools that server offers.

One thing I needed to research was what “discovering” those tools entails. An AI assistant does not roam the internet looking for MCP servers that might help answer a question. Publishing an MCP server would not mean that a random knitter could ask an unconfigured assistant about increases and have it spontaneously find my calculator. My MCP server must first be connected to the knitter’s AI application.

During development, that might involve me manually entering the server’s address in my prompt to the AI assistant. However, for ordinary users, I would need to package the connection as a knitting-calculator plugin and publish it in a directory supported by their AI application.

Even then, I think it is unlikely that knitters will simply stumble across it. They might find it by searching a plugin directory, but the more likely route is that I tell them about it through my website, blog, or app and give them a link for installing it. An MCP server would help me serve people who already know about the calculator, not magically find an audience for it.

Once connected, the AI application could ask the MCP server which tools it provides. My server might offer tools with names such as:

• calculate_even_increases

• calculate_even_decreases

Each tool would describe the inputs it requires and the result it returns. When a knitter asked a matching question, the assistant could select the appropriate tool, provide the stitch counts, and use the returned calculation in its answer.

A skill would play a different role. The MCP server would provide access to the calculation, while the skill would teach the assistant how to use that capability well. For example, it could tell the assistant to ask for missing stitch counts, recognise ambiguous requests, call the calculator instead of attempting the arithmetic itself, and explain the result using familiar knitting language.

The skill would not normally live inside the running MCP server. It would be a separate collection of instructions installed in the AI application. An installable plugin could package the skill together with the configuration needed to connect to the MCP server:

Knitting Calculator plugin
├── Skill
│   └── Instructions for handling knitting questions
└── MCP connection
    └── Hosted MCP server
        └── Calculator library

This would give knitters one thing to install. They would not need to understand the distinction between a skill, a plugin, and an MCP server in order to use the calculator.

I plan to keep the skill open source on GitHub so that anyone can inspect, adapt, or install it manually. I will also include it in the installable calculator plugin. Most knitters could simply follow a plugin installation link, while more technical users would still have access to the skill itself.

To summarize:

• The calculator library performs the calculation.

• The API makes the calculation available through a public web request.

• The MCP server presents the calculation as tools an AI application can call.

• The skill teaches an AI assistant when and how to use those tools.

• The plugin packages the skill and MCP connection into something a knitter can install.

None of these should contain separate versions of the knitting calculation. They should all depend on the same underlying calculator.

An MCP server will not introduce my calculator to the world or cause AI assistants to prefer it automatically. What it will provide is a reliable path from a knitter’s question to my tested calculation engine, once that knitter had chosen to install the integration. And, quite honestly, building it would also be a fun way for me to learn how all of this works.

A library with a command-line interface

There is an important distinction between putting the calculation inside a command-line program and giving a calculation library a command-line interface. The command-line tool should not be the calculator itself. It should be one way of using the calculator.

If the business logic lived only inside an executable, an iOS app or website could not easily import it. They might have to launch the executable as a separate process or recreate the calculation elsewhere.

Instead, the calculation will live in a standalone library. The command-line tool will import that library, provide it with some inputs, and print the result. It will contain no calculation logic of its own.

The structure will look something like this:

Calculator library
├── Command-line tool
├── iOS app
├── Website
├── Public API
└── MCP server

Starting with the command-line tool will test the separation I care about. If the calculator can accept inputs and produce useful instructions using nothing but text, then its essential behaviour does not depend on buttons, navigation, or screen layout.

Later, the iOS app and website can become graphical interfaces to the same library. The public API and MCP server can provide other ways to reach it. Each interface may present the calculator differently, but none of them should need to reimplement it.

Flexibility without building the future

That does not mean I am going to build all of these interfaces now. There is always a danger in designing for hypothetical future requirements, and I do not want to spend weeks building infrastructure for users who do not yet exist. The first version will remain intentionally small: a thoroughly tested calculator library and a command-line tool.

The point is not to predict every place the calculator might eventually run. It is to build the first piece in a way that does not trap it inside the first interface.

What began as a technique for keeping business logic separate from an iPhone screen turned out to be a much broader architectural idea. Good mobile architecture and AI-assistant-friendly architecture share the same foundation: the useful part of a product should not be trapped inside its current interface.

So, before I build the app, I am going to build the calculator.