Every product with an API should ship an MCP server, and products without one should ask why not. The reasoning is narrow: an agent acting on a user's behalf can only reach software that exposes a machine-callable surface, so a product that can only be driven by a human clicking is unreachable to that user. It is not a bet on agents replacing interfaces, it is the observation that a second class of user has appeared and most software has no door for it.
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026.
Every product across this portfolio ships an MCP server and a CLI alongside its interface. This is why, and where the rule stops.
What changed about who uses software?
The operator changed. For about thirty years every product shipped on the same assumption, a human would sit in front of it, and the interface was the product.
Careers went into funnels, onboarding flows and the precise shade of a button, all aimed at a person clicking. That assumption is now partially wrong, and the part that is wrong is growing. Increasingly the thing that arrives to use a product is an agent, acting for someone who described what they wanted and went to lunch.
If a product can only be driven by a human through a UI, then to that agent, and therefore to the person who sent it, the product is effectively absent. Not worse. Not slower. Absent, behind a door only a hand can open.
What is MCP actually for?
MCP is a protocol for exposing tools, resources and prompts to a model in a way any compliant client can discover and call.
The important word is discover. A bespoke API integration requires somebody to have written that integration in advance. A protocol means a client the vendor has never heard of can connect, enumerate what is available, and use it. That is the difference between being integrable and being reachable, and only the second one scales past the integrations someone chose to build.
The specification covers tools the model can call, resources it can read, and prompts a server can offer. A CLI does a related job for a different consumer, the shell, the script, the cron job, the other program, which is why both ship rather than one.
A private API means an agent can use your product if somebody wrote an integration first. A protocol means it can use your product without anyone asking your permission or your roadmap.
Does that mean interfaces are finished?
No. The interface gets demoted, not deleted, and the difference matters.
The UI stops being the only door and becomes the place you go when you want to look, to inspect, to trust, to enjoy, to do the thing that is genuinely better with your hands and eyes. Plenty of work is better that way, and plenty of decisions should never be delegated. What changes is that the interface stops being the sole representation of the capability.
The asset was never the interface. It was always the capability behind it. Products where that capability is exposed directly are usable by both classes of user; products where it is welded to a screen are usable by one.
| Surface | Serves | Fails when |
|---|---|---|
| UI | A human who wants to look, judge or enjoy | Something else is doing the work |
| API | An integration somebody deliberately built | Nobody built the integration you needed |
| MCP server | Any compliant client, including ones you have never heard of | The tool surface is bloated or the descriptions are poor |
| CLI | Shells, scripts, pipelines, cron | The task is genuinely interactive |
What does shipping it actually cost?
It costs real work, and the honest answer is that it is not free.
A good MCP server is not an automatic wrapper around your endpoints. Tool descriptions are prompts and get read before the user's first turn, so they have to be written for a model rather than for a developer browsing reference docs. Tool surface consumes context whether or not anything gets called. Write tools need real idempotency, because the protocol offers a hint that defaults to false and explicitly is not a guarantee. And every exposed tool is attack surface, descriptions are untrusted input rendered into a model's context.
Those are the mistakes I have made repeatedly enough to write rules about. The cost is real. It is just smaller than the cost of being unreachable.
When should a product not ship one?
Do not ship one when there is no meaningful capability behind the interface, or when exposing it creates risk you cannot contain.
A product whose entire value is the experience, a game, a drawing tool, something where the interaction is the point, gains little from a machine surface, and building one is work spent for nobody. If you cannot name a task an agent would reasonably want to perform, you do not need a server yet.
More importantly: do not expose write capability you cannot make safe. An agent can be argued into calling a destructive tool, so anything irreversible needs the guarantee to live in your code rather than in a hint or a description. Where consent genuinely matters, money moving, data leaving, something being published, a human confirmation belongs in the path, and no protocol removes that obligation.
And do not ship one to look modern. A neglected server with stale tools is worse than none, because it fails in ways the caller cannot diagnose.
The rule is not "expose everything to agents". The rule is that a capability worth having is worth being able to reach, and anything irreversible needs its guarantee in code, never in a description.
How do you decide, per product?
Ask whether a capability exists, whether an agent would want it, and whether you can expose it safely.
SHOULD THIS PRODUCT SHIP AN MCP SERVER?
The Hopium Lab · v1.0 · 22 July 2026 · take it, fork it, argue with it
1. IS THERE A CAPABILITY, OR ONLY AN EXPERIENCE?
[ ] Name three tasks an agent would plausibly want to perform
[ ] If you cannot, stop here, you do not need one yet
2. CAN YOU DESCRIBE EACH TOOL TO A MODEL?
[ ] One sentence, no jargon, stating what it does and when to use it
[ ] If two tools need the same description, you have one tool
3. WHAT HAPPENS ON A BAD CALL?
[ ] Which tools are irreversible? Those need enforced idempotency
[ ] Which need human consent? Put it in the path, not in the description
[ ] Assume the model was talked into it by hostile input
4. WHAT DOES IT COST BEFORE ANYONE CALLS ANYTHING?
[ ] Total bytes of names, descriptions and schemas at connection
[ ] Every host connecting pays that, every session
5. WILL YOU MAINTAIN IT?
[ ] A stale server fails in ways the caller cannot diagnose
[ ] If you will not keep it current, do not publish it
THE TEST: if an agent could do the job through your MCP server without the
user ever opening your app, is that a success or a threat? If it reads as a
threat, your product is the interface, and you should know that about yourself.
That last question is the one worth being honest about. Plenty of businesses are monetised on attention rather than outcome, and for those, an agent completing the job invisibly is genuinely bad news. Better to know which one you are than to ship a machine surface into a business model that quietly depends on the human staying.
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026.