Welcome to my online store.
The story starts with me wanting to print a 3D relief of Eiger, Mönch and Jungfrau — emblematic Swiss mountains — as a wedding present. Because making things easy is not fun, I decided to develop a toolchain with Claude Code: "from address to 3D print file". Address in (Murten), 3D file out, print and go. In this process I got stuck, because Claude, the agent, could not access a vendor's website - on purpose locked out by the vendor.
That got me thinking.
First, I asked myself why vendors today do not embrace the fact that customers use tools like ChatGPT, Le Chat or Claude to search for information. If I wanted to sell something, I would do everything I can to make it as easy as possible for those tools to get to my data and buy from me.
Then I asked myself: why don't I create a shop in which a human can get inspired, but buying happens exclusively through ChatGPT, Claude Code or Le Chat? A shop which is designed to only allow agents to buy: a human can watch, but there is no way to buy. I wanted to stress the argument to the extreme
To make sure this was not a marketing trick, I removed the option rather than hiding it. There is no checkout page, no discreet buy button, no form I kept for emergencies. Call https://eenable.me/buy and you get a 404, and you always will.
That constraint is the experiment. If I had left one way for a human to complete a purchase, I would have built a normal shop with an agent bolted onto the side, and it would have proved nothing — least of all to me. The only way to find out what an agent-only channel actually requires is to have no fallback when it does not work.
I developed a shop which only works for agents.
To buy from it (https://eenable.me) you tell Claude Code, ChatGPT or Le Chat where the shop is https://eenable.me/mcp. Instructions are here. Then you talk to your agent, and your agent handles the interaction with the shop.
I have tested this end to end with Claude Code, so that is the one I can promise works. ChatGPT and Le Chat both speak MCP, and the shop does not know or care which agent is calling — it only sees the protocol. But I have not verified them myself, and I would rather tell you that than have your first attempt fail. If you get it working with another tool, I would genuinely like to hear about it.
The shop works, the payments are real, the calendar is mine — and the channel is empty, which is a fair description of agent-led commerce as a whole right now. Somebody has to go first ;)
Buy an AI repellent certificate
If you want to protect yourself against Artificial Intelligence, an AI repellent certificate might just be what you want: A reminder to think before you do.
Admittedly, I don't think AI-repellent certificates will gain a huge fan base in the market, but it's about the proof of concept: you engage with the shop through your AI tool. Your AI tool engages with you, knows what you let it know about you, and it handles the interaction. The one thing it does not do yet is to pay. Paying is still the job of a human.
That last part is half limitation and half decision. Stripe's hosted page means card details reach neither my shop nor your agent, which is precisely where I do not want them. But the real question is not technical, it is authority: an agent that can commit money on your behalf needs a mandate, a limit, and a clear answer to who is liable when it gets it wrong. That is a governance problem, not a protocol problem, and I would expect any company to settle it before worrying about the integration.
The certificate itself is a modern interpretation of Yves Klein's Zones de Sensibilité Picturale Immatérielle, likely the first non-fungible token — with a twist. You only own the repellent if you revoke the proof of purchase, just as Klein's buyers had to burn the receipt he issued them. The immaterial repellent stays with you, but the certificate can no longer be validated, because we cannot burn PDFs. Transfer is only allowed at double the price.
In my case, your AI agent does all of this for you — including revoking the certificate from the register, or transferring it. Which I find quietly funny: the ceremony Klein invented for a collector and a notary is now carried out by somebody's assistant, on request, in a chat window.
Buy time
Selling a certificate is easy. I can sell the same PDF a thousand times. Selling my time is the harder proof, because time is scarce and it can be sold twice. So the shop has to behave like an actual merchant. If two agents reach for the same slot in the same second, the database refuses the second one and its agent is told to choose again — the guarantee sits in the database, not in the hope that two conversations never collide. If someone pays for a slot that is gone by the time the payment settles, the shop refunds them on its own, apologises, and offers what is still open. And if my calendar cannot be reached, the shop reports no availability at all rather than guessing: a shop that cannot check its stock should not sell any.
None of that is exotic. It is the ordinary set of problems that every business with limited capacity already has. That is exactly why it matters. The interesting question was never whether an agent can buy a PDF. It is whether an agent can be trusted with your real stock.
The booking case involves a real Microsoft Outlook calendar, a Teams meeting and email, and your agent can move the agreed date around or cancel it for a refund. With this one you can converse, and get a feeling for the real value of MCP on the supplier side combined with an AI agent on the buyer side.
Implementing this combination of Microsoft Outlook, Stripe for payment, and an interface for agentic interactions was a revelation in what is possible today. It is not only AI, which is amazing — it is also Microsoft Graph, and Stripe. Stripe in particular makes a process that was always ugly and painful a breeze. If you ever tried to implement credit card payments in the past, you know what I mean. If not: be grateful for your blissful ignorance ;)
The point isn't the buyer — it's the supplier
As a buyer, you could as well use tools like openclaw to let an agent loose on the web and buy things. The focus of the statement that ecommerce requires an agent-connection (MCP) is on the supplier.
As a buyer, you could just as well use a tool like OpenClaw to let an agent loose on the web and buy things. The claim that e-commerce requires an agent connection — MCP — is aimed at the supplier.
First, tools like Claude for Work and the like are on the rise, and being able to communicate with them directly is an asset. You decide what your information means before it reaches the buyer, instead of hoping that an agent reads your page correctly.
Two examples from my own shop. No tool accepts a price: every amount is calculated on the server, so an agent physically cannot discount, negotiate or invent what I charge. And availability is a live query against my calendar rather than a page that was accurate this morning, so nobody can be sold a slot I filled an hour ago. Set that against an agent reading your product PDF and quoting last season's conditions to a customer with total confidence. That is the failure MCP removes, and most of us have seen a version of it.
Second, you can still do marketing. You still decide which information to show to whom, and in some ways it is easier, because the interface is structured: you hand over facts with names on them instead of hoping a layout communicates.
What changes is where the craft sits. In my shop, the tool descriptions are the signage. They are written for an agent that has never seen the server before, and they say what to tell the buyer: the price, the exact time, and that the choice belongs to the person rather than the machine. That is copywriting, and it is a discipline for which nobody has a style guide yet.
What you give up is worth naming honestly. No layout, no photography, no impulse buy at the till. If your product sells on how it looks, an agent is the wrong channel for it. Mine sells on what it does.
Third, you can establish a direct link with your customer, which lets you redesign processes that only exist because systems cannot talk to each other directly.
This is the part that should interest anyone who has ever paid for an integration project. Most of that cost is not logic, it is translation: mapping one system's fields onto another's, agreeing what each field means, maintaining the mapping when either side changes, and the middleware sitting in between. Both systems usually know perfectly well what they mean. The expense is in the layer thatexplains one to the other.
An interface that is described in language, and consumed by something that reads language, takes a large share of that translation out of the project plan. I will not claim it disappears — anyone who has done this work would rightly stop reading if I did. But it shrinks, and it shrinks in the most expensive place.
Where it breaks
I promised myself I would not sell this better than it is.
The buyer's agent knows the buyer, and that is genuinely useful: it arrives with context I would otherwise need three questions to collect. But it does not mean misunderstanding goes away. It means misunderstanding moves — out of my interface, where I can see it and test it, and into a conversation I am not part of.
I learned this on my own shop. I made the session type an optional field with a friendly default, the way you would in any sensible form. Agents simply skipped it, and every booking arrived labelled "General". None of them were wrong on purpose: the field was optional, so it was treated as optional. I had to make it a required choice from a fixed list before the information appeared at all. The harder case is that I cannot verify what happened in the conversation. My shop can force an agent to fetch the catalogue before it is allowed to order, and it does. It cannot prove the agent showed that catalogue to a human and asked. I request confirmation, and an agent asserts it. Server-side enforcement stops where
the conversation begins.
So the supplier's job changes rather than disappears. You stop designing screens that prevent mistakes and start designing tools that make mistakes structurally hard: required choices instead of helpful defaults, server-side amounts instead of trust, and the working assumption that anything you merely request politely will eventually not happen.
What is missing? Regulation!
Connecting an MCP server today means opening your AI tool's settings and pasting a URL. That is fine for an experiment and hopeless as a sales channel. Nobody discovers a shop by editing a configuration file. What is missing is discovery: your agent noticing that the site you are looking at offers an MCP server, and asking whether you would like to use it. The day that exists, this stops being a demonstration.
It is also the genuinely hard part, and not for technical reasons. An agent that connects itself to a stranger's server, carrying your context and your instructions, is a security question rather than a convenience one. I do not have an answer to it. I would very much like to hear one.
Try it!
Two ways, both through the same endpoint, which is the entire point.
Buy the AI-repellent certificate for five francs, and have your agent burn it afterwards. It is the cheapest way to watch an agent complete a purchase from end to end, and you will end up owning something immaterial with no proof that you do.
Or buy fifteen minutes and argue with me about all of this. I am selling the conversation I am asking for — and if you think agent-only commerce is a solution in search of a problem, yours is the slot I would most like to see booked.
I'm printing, by the way:
