How I built Copix, a copywriting MCP server, in two days

Why build it at all?

The problem in the spec is one sentence: people who already write with an AI and hate how it sounds, and who do not want to paste a 2,000 word prompt every time they need a sales email.

I had already written that prompt, many times over. The copy module in Nexin is a set of skills for exactly this: hooks, frameworks, storytelling, a scrubber for AI tells and a natural speech pass. They work, but they work as files you install, and they assume you have filled in brand files first.

Copix asks for nothing up front. You connect it once and any client that speaks MCP can call it in the middle of a draft.

The decision that made it cheap to run

The core line in the spec is "a toolbox for the model, not a second model".

When your assistant calls copy_framework or humanize, Copix does not send your text to another AI. It returns the relevant part of a versioned library and runs deterministic checks on the draft. Your model reads that and does the rewrite.

That choice paid for itself three ways:

• A copy call costs milliseconds of CPU. So the copy tools cost no credits and have no usage limit.
• Nothing to hallucinate on my side. A check that counts opening words or flags a pattern gives the same answer twice.
• The library is never sent whole. Each brief gets only the piece it needs, which keeps responses small and the library mine.

The SEO tool is the exception. Judging whether a query fits a site, or whether a draft makes a promise it cannot keep, needs a model. Those calls go to TypeSafe's Jev and to jev-seo, an MIT licensed SEO toolkit by Akash Priyadarshi that Copix runs as a pinned binary. Every SEO action has a fixed credit price and a hard cap on what it may spend, and the client refuses a request before it goes over budget.

I measured the real spend on 8 October against one of my own sites: every SEO action came in under 5% of its cap.

What the fork kept and what it threw away

The first commit forked Nexin, renamed it and gave it a new palette and logo: 331 files. The second commit deleted 3,435 lines: Nexin's modules, stacks, skills, prompts, downloads, paywall and zip builder.

What stayed was everything I did not want to build twice: Stripe embedded checkout with its currency handling, magic link sign-in, Mailgun, encrypted personal data, analytics and the Railway Dockerfile. The stack is Rails 8.1, PostgreSQL, Solid Queue and Solid Cache inside Puma, and small vanilla TypeScript modules on the front end. One container on Railway. It is the same boring stack I describe in the solo founder tech stack, and it was boring on purpose.

The repo has one rule about the fork: anything still shaped like Nexin gets replaced, not extended. By the last phase nothing a user sees was.

The build, in the order it happened

The MCP server itself is a hand-rolled JSON-RPC dispatcher over stateless Streamable HTTP, JSON only. I did not use a gem for it. The protocol surface a tool server needs is small, and owning it meant I could read every line of it when something misbehaved.

Where the time actually went

OAuth for the chat apps

Developer clients take an API key in a header. Claude.ai and ChatGPT want OAuth 2.1, with dynamic client registration, resource indicators and the MCP discovery documents. The usual Rails OAuth library does not cover those, so I wrote that part by hand too. It is the least glamorous commit in the repo and the one that decides whether a non-developer can connect at all.

Clients cache the tool list

An MCP client asks a server for its tools once and caches the answer. A stateless server cannot tell it the list changed. So when somebody upgrades to the plan with SEO, the seo tool does not appear until they refresh the connector by hand.

I could not fix that in code. The fix is an instruction with a screenshot in the app, at the moment it matters.

What the eval caught

I wrote a script that runs four throwaway accounts through every tool inside a database transaction that rolls back. It found four things the test suite had not:

1. The draft check opened with "check_draft: ok." Models read that first line as a pass and stopped reading. It now leads with the verdict.
2. The FAQ check counted every question on the page. It now counts only the questions under the FAQ heading.
3. One field came back as a pair of falses where a list of skipped checks belonged.
4. The story check flagged strong stories as weak, because its word lists were too narrow.

An earlier false positive was the same kind: humanize flagged list items for starting with the same word, which is what list items do.

None of these were crashes. Every one was a tool giving a model a wrong impression, which is the failure that matters when the reader of your output is another AI.

How it works now

You connect once:

• Claude Code, Cursor, VS Code, Windsurf: create a personal key in the app and add the server with one command.
• Claude.ai and ChatGPT: add it as a connector and sign in.

Then you write the way you already do. The assistant calls the copy tools when it needs a structure or a voice pass, and the seo tool when you ask it to pick queries, check a draft, audit a page or crawl a site. The SEO answers no longer name the engines underneath; the credits page does.

Privacy was a design rule from the start: every call writes a usage row with the input's size and a SHA-256 digest, never the text itself.

I wrote ten posts for the Copix blog with Copix: queries picked with the seo tool, structure from the frameworks and hooks, and every one passed humanize and the draft check before it shipped. If you want the manual version of that workflow, building a SaaS with AI covers how I direct the model and read every line.

What I cut for later

The spec lists the next candidates and none of them are built: a voice tool, offers, headlines, email, ad copy, an SEO brief and a citation check. A head-to-head eval of Claude and ChatGPT with and without Copix is still unticked in the plan. Shipping four copy tools and one SEO tool that work beat shipping ten that half work, which is the same cut I argue for in scoping an MVP.

Who it is for, and who it is not for

For: founders, solo marketers, copywriters, agencies, creators and SEO writers who already draft with an AI and want the output to stop sounding like one.

Not for:

• People who want an editor. There is no writing app. Your assistant is the editor.
• People who want keyword volumes. The query tool judges fit, audience, intent and overlap with your own posts, and says plainly that volume is not measured.
• People who want a subscription. There is none.

And if the copy is fine but nobody reads it, the bottleneck is distribution, which is what SEO for a small SaaS is about.

---

Copix, if your AI writes and you hate how it sounds

A note on fit first. If you write rarely, or you are happy pasting one long prompt, you do not need a server for it. Copix does not pick your offer, and it will not make a weak argument persuasive.

Copix plugs into the assistant you already use and gives it copy frameworks, hook families, story structures, a pass that removes AI tells, and an SEO engine for queries, drafts and live pages. Your model keeps doing the writing.

See Copix