Set it and forget it. The slow cooker you filled at seven in the morning and trusted with dinner. The robot vacuum you let loose while you were at work, which did clean the whole house and also found one thing on the rug and took it everywhere. The subscription you set to auto-renew in 2019 and have funded ever since, quietly, like a small pension for a company you cannot name.
We love a thing that runs without us. So of course the newest one is a website you can talk to.
I did not go looking for this. I went looking for EmDash, Cloudflare's new content management system, in our own crawl data, because a platform pitched as the spiritual successor to WordPress is the sort of thing that eventually turns into somebody's migration project and therefore eventually turns into my problem. I found almost nothing, which I expected. Then I read the documentation instead, got as far as the reference page for something called the MCP server, and stopped thinking about migrations for about an hour.
What is actually in the box
Every EmDash site ships with a Model Context Protocol server mounted at /_emdash/api/mcp. It is on by default. You do not install it, you do not enable it, and if you want it gone you have to go into your Astro config and say so out loud with mcp: false. It always requires authentication, so nothing is hanging open, but the door exists on every site whether or not the owner ever notices it.
What it does is let an assistant like Claude or ChatGPT work on your content directly. Not generate a draft you then paste somewhere. Work on it. List what you have, search it, compare versions, create entries, update them, publish them, take them down again. You connect it the way you would connect any other tool, by adding your own domain as a custom connector, and after that you are having a conversation with your website.
Which is, I want to be clear, genuinely great. I am not building up to a scold. The first time you realise you can ask a question about your own content and get an answer instead of a search results page, something clicks about what this stuff is for.
The part where you hand over a key
Here is where the slow cooker metaphor runs out and a better one takes over, which is that you have hired a house-sitter.
A house-sitter is a wonderful arrangement built entirely on one decision you make at the door: which key do they get. EmDash calls these scopes, and the two that matter are content:read and content:write. Read is the guided tour. They can look at everything, search the drawers, tell you what is in the attic. Write is the other thing. Write means create, update, delete, publish and unpublish. Write means your house-sitter can rearrange the furniture and then go tell the neighbours about it.
There are three ways to hand over that key. There is a proper OAuth flow with a browser consent screen. There is a device flow, the kind where a code appears and you approve it. And there are personal access tokens, the ec_pat_* strings you generate in the admin panel, which the documentation describes as long-lived, and which are therefore the spare key under the mat: enormously convenient, and still under the mat in two years when you have forgotten which of the four people you gave it to.
The detail I keep turning over is on the consent screen. When a client asks for scopes, all of the requested ones are ticked by default, and the documentation is refreshingly honest about why: compatibility. You can untick them before you approve. You cannot add scopes the client did not ask for, the grant is still bounded by what that client registered and by your own role, and an empty grant is rejected outright, so there is real engineering behind it. But the default state of that screen is yes to everything, and the number of people who read a consent screen carefully at the end of a setup flow is not a large number. (You have approved one this month. Do you remember what it said?)
None of this is a flaw, exactly. Defaults that fail closed annoy people into turning the whole feature off, and a feature everyone disables protects nobody. It is just that publishing used to be a deliberate physical act. Somebody sat in an interface and pressed a button and could be asked about it later. Publishing is now a scope. It is a checkbox on a screen you saw once, in a flow you were trying to get through, on a Tuesday.
Why this lands on my desk and not just the security team's
Because an assistant with a key to your house is only as useful as your house is organised, and this is the thing I did not expect to find at the bottom of a protocol reference.
Ask an agent to update every page that mentions your old pricing, and what happens next depends entirely on whether your content is content. If your pages are structured, with real fields and real relationships, the agent does the boring thing correctly in about nine seconds. If your pages are a soup of page-builder shortcodes, with the actual words buried inside layout wrappers that only one plugin understands, the agent does what every tool does when handed that: it guesses, or it declines, or worse, it succeeds partially and you find out in March.
That failure is not new and it is not about artificial intelligence at all. It is precisely, exactly, boringly the same failure that makes a platform migration expensive. Content locked in a builder does not export. Assets pinned to one platform's paths do not move. A page that is an empty shell until the scripts run cannot be read by a migration tool, and it cannot be read by your new assistant either, for the same reason, in the same way.
So the two questions turn out to be one question. Can I talk to my site, and can I ever leave this platform, are both the question can a machine that is not this platform understand what I have written. If the answer is no, the assistant is a party trick and the migration is a rebuild.
How early is early
Very, and also not as early as I assumed, which is the part that made me sit up.
We went looking for EmDash across 257,638 archived pages covering 255,003 domains in our own crawl, matching on the reserved /_emdash/ paths the platform leaves in its own markup rather than on the word emdash, because a site writing an article about a content management system is not a site running one. Two pages came back, on two hosts. One of them no longer shows it. The other is toysrus.ca.
I re-checked that by hand today, because a national toy retailer running a platform whose 1.0 is still described as coming soon is exactly the sort of result you should distrust before you repeat it. Their homepage preloads eleven images from /_emdash/api/media/file/. Their /_emdash/admin answers with a redirect to authentication, while a made-up path on the same domain answers with a plain 404, so the namespace is genuinely mounted and not a catch-all being polite to me. It is real. Toys R Us Canada is serving its homepage imagery out of Cloudflare's new content management system.
Two hosts is not a trend and I am not going to pretend it is one. It is also a floor rather than a share, and it is worth saying why: our sample is apex domains, and the early adopters of a developer-first platform are documentation sites and engineering blogs living on subdomains. Cloudflare runs EmDash on their own blog, which our sample structurally cannot see. When somebody eventually publishes an EmDash adoption figure, ask them what they crawled before you believe it, including if that somebody is us.
What I would actually do
I think the MCP server is the most interesting thing about EmDash, and I think the WordPress successor framing undersells it. Plenty of platforms will bolt an assistant on. Shipping one mounted by default, with a real scope model and an OAuth flow behind it, as an ordinary part of what a website is, is a different claim about what a content management system is for.
But I would not migrate anything this quarter on the strength of it. What I would do, this month, on whatever you are running today, is find out whether your content is legible to something that is not your CMS. Open a page and ask whether the words are in the markup or assembled later by scripts. Look at whether your asset paths name your current platform. Check whether your structure is real fields or one enormous blob with styling in it. You will learn more about your next five years from that half hour than from any feature comparison, and it costs nothing.
Then, when you do hand somebody a key, at least you will know what is behind the door. Read the screen. Untick a box. Your house-sitter does not need to get into the attic on day one.