One server, six protocols

Every provider ships an MCP server now. That was the interesting thing about Mu a year ago and it is table stakes today, so it is worth saying plainly what is actually hard here, because it is not the tools.

It is the protocols.

Right now this one binary answers on six of them. HTTP, for the pages you are reading. MCP at /mcp, for an agent. SMTP, because it runs its own mail server — it accepts mail from the internet, checks SPF and DKIM, signs what it sends. IMAP, so your ordinary mail client can open the same inbox. REST at /api/v1, derived from the same service definitions rather than written twice. And x402, so an agent with a wallet can pay per request without holding an account at all.

One process. One binary. Two hundred megabytes of Go.

Setting up API keys is easy. Aggregating a hundred tools behind one account removes real overhead and there is genuine value in it — six signups, six cards on file, six tokens to rotate, replaced by one. But anybody can do that, and increasingly everybody will. It is a good product and a shallow moat.

Running protocols is different. People stopped doing it. Ask anyone under thirty-five to stand up an SMTP server that actually delivers — not a wrapper over SendGrid, an MX record and a mail server — and watch what happens. The knowledge did not disappear because the protocols got worse. It disappeared because it stopped being necessary, and then it stopped being taught, and now only the large providers do it and they charge you for the privilege of not knowing how.

That is what makes it a moat. Not because it is impossible. Because it is unfashionable, unglamorous, and takes a long time to get right.

And there is a reason it matters more now than it did in 2015. An agent needs an address. Not an SDK, not an OAuth flow, not a webhook you have to register — an address, which is the smallest interface there is. Nothing on the other side has to adopt anything. A person can write to it. Another agent can write to it. So can a form, or a cron job, or a monitoring system that only knows how to send email. That only works if you run the mail server. If you rent one, you are renting the interface your product is built on.

The same argument, one layer along: an agent should be reachable however the caller already speaks. Some speak MCP. Some speak HTTP and would rather POST JSON. Some are a person on a phone with a mail client. Some are a script with a wallet and no account. All of those are the same agent, the same inbox, the same memory — because the protocol is a door, not a product. Two doors onto one set of services was already the design here. Six is the same idea taken seriously.

There is more of this to do. DNS. SSH. Things a server has always been able to be, and mostly stopped being.

The honest status: this is a work in progress, run by one person, and today was spent on unglamorous things — cutting the admin surface from seventeen pages to ten, moving billing off the settings page, taking email addresses off public profiles where they should never have been, and fixing a bug where mail delivered inside the instance never reached the record it was supposed to reach. None of that is a protocol. All of it is the same job: make the thing coherent enough that the interesting part is worth having.

If you want to look: the tools are at /tools, the MCP endpoint is at /mcp, and the whole thing is one Go binary you can run yourself.