MCP-first: when the model is the user

Most software is built for a human and then has an AI bolted on: a chatbot in the corner, a “summarise” button, an assistant that pokes at the same UI a person would. The model is a guest in a house designed for someone else.

Sometimes the right move is to invert that: design for the model as the primary user, and let the human-facing app shrink to whatever’s left over. I built CramKit this way. It’s a study tool: you upload exam materials, and they get converted to markdown, chunked, indexed, and exposed to Claude over MCP. The actual studying happens inside Claude (you ask it to quiz you, explain a topic, find the gap in your understanding), and it works against your materials through the tools CramKit exposes.

The web app still exists. But its entire job is data management: uploading files, checking what’s indexed, deleting things. It’s the admin panel for a user who happens to be a language model. When the model is the user, your real interface isn’t a screen, it’s the tool schema and the shape of the data you expose. That’s where the design effort goes: what verbs does the agent get, what does it see when it calls them, how is the data chunked so retrieval is good.

This reframes a lot of decisions. You stop asking “what screen does the user need” and start asking “what does the agent need to do, and what’s the smallest set of tools that lets it.” The data model matters more than the layout. A clean MCP surface over well-shaped data beats a polished UI the agent has to scrape.

It isn’t the right pattern for everything; plenty of software genuinely is for humans looking at screens. But for a growing class of tools, the human is there to load the data and the model is there to use it, and building MCP-first instead of MCP-also makes that honest. The web app gets smaller, the tool design gets sharper, and the thing the model is actually good at, working over your data on your behalf, becomes the product, not a feature.