1. Home
  2. Blog
  3. Why Most of My Products Are MCP Servers
Build log

Why Most of My Products Are MCP Servers

Eight of the products I built in October are MCP servers: you connect them once to Claude, ChatGPT or Cursor, and from then on you use them by asking in the chat. I build them this way because the AI is already good at writing and deciding. What it cannot do is render a video, remember yesterday’s chat, read live data or post at 9am tomorrow. That is the part each product does.

What is an MCP server, in one paragraph?

MCP (Model Context Protocol) is a standard way to give an AI assistant tools. A server describes its tools (name, inputs, what they return), and the assistant calls them when your request needs them. Claude, ChatGPT and editors like Cursor all speak it, so one server works in all of them.

The split: the AI writes, the server does

Every one of my MCP products follows the same rule: no writing model runs on my side. The assistant you already pay for writes the copy, the slides, the timeline or the report. The server does the work a language model can’t do alone.

Product The AI does The server does
Karou Writes the slides Renders them as carousel PNGs
Klevo Drives the web app, writes captions Records the browser and renders the MP4
Cut Express Decides every cut, caption and sound Renders the video with FFmpeg
Valta Decides what to save and link Keeps the Markdown vault for every AI
Copix Writes the copy Hands over the method, reviews the draft, runs SEO checks
Vettoz Writes the report and the brand Collects and scores buyer signals, checks domains
Kalen Writes the posts Researches the niche, scores drafts, publishes on schedule
Nexin Follows the prompt or skill Serves the library and fetches real data

This split keeps the products cheap to run and honest about what they add. If a tool only wrapped a writing prompt, you could paste the prompt yourself.

What does one of these apps look like inside?

Each product is a single Rails 8 app in one repo:

  • The public site: landing page, blog and legal pages, server-rendered for SEO.
  • The MCP endpoint: one route, with the tools registered in one place and every call logged by size, never by content.
  • OAuth: so Claude and ChatGPT can sign in with your account, plus API keys for editors.
  • Billing: plans or credits, checked on the server, never trusted from the AI.
  • Workers when needed: a Python worker for video in Cut Express, a browser worker for recording in Klevo.

Because the shape is the same, a new product starts from the last one. That is how nine products fit in two weeks.

What did I learn the hard way?

  • Ask before spending. Any tool that costs money or credits answers the first call with the price and the balance and runs nothing. The AI asks you, then calls again with a confirmation.
  • Refresh after schema changes. Clients cache the tool list. After changing a tool’s inputs, claude.ai needs a “Refresh tools list” before it sees the new shape.
  • Write tool descriptions for the model. The description is the manual the AI reads. Short steps, the order to call things in, and what never to do work better than marketing copy.
  • Give the product a voice. Every result carries one line in the product’s own voice, which the assistant relays. It makes Copix feel like Copix and not like a generic tool.

When is an MCP server the wrong choice?

When the product is the interface. LaunchGP is a race-style launch directory people browse, so it is a website. BatchTone grades a whole shoot of files on your Mac, so it is a Mac app. And Project K is a game. Chat is a great remote control, not a replacement for every screen.

See every product, MCP or not, in the build log.