How your AI agent finds a place to publish your website

When you ask an AI agent to publish your site, it does not go looking for the best host. It reads a handful of files a service leaves at fixed addresses, written for machines rather than for you, works out which way in it is able to use, and then stops at the one decision it is not allowed to make on its own: your permission.

This is for people who have watched that happen and wondered what the agent was actually reading. There are no setup commands here, because the connection guides have those, tool by tool.

Your agent is not shopping for a host

Most people describe something like a search: the agent surveys the options, weighs them up, picks the best one. That is not what happens, and the real answer is duller than the guess.

There is no catalogue and no registry. No index of publishing services an agent can consult, no ranking, no agreed way for a service to announce "this is what I do" in a form every agent understands. Google, announcing its own attempt at fixing that in June 2026, put the state of things plainly: "Today, there is no standard way to answer those questions across organizations." Its proposal puts a catalogue file at a fixed path on your domain, one proposal among several, months old.

So an AI agent arrives at a service in one of three ordinary ways. You named it. It is already connected, because you set that up once and forgot. Or you handed it an address and it went and read what was there. That is the entire list.

Which means the interesting question was never how an agent chooses between hosts. It is what happens once it has an address. That part really is automatic, and it really does involve a decision.

What a machine reads at a fixed address

Three things, and all of them are plain text.

The first is an index at the root of the site. Ours sits at /llms.txt: a short plain-text file saying what the service is, who it is for, and how to connect. Where that file comes from, how it is laid out and whether anyone actually reads it is a separate article. The part that matters here is that a person wrote it and the intended reader is a machine.

The second describes how to ask permission, and this one is not a convention but a requirement. The Model Context Protocol's authorization specification states that a server "MUST implement the OAuth 2.0 Protected Resource Metadata (RFC9728) specification to indicate the locations of authorization servers." In practice the agent makes a request with no credentials, receives an HTTP 401, and the refusal itself carries the address of a small metadata document. If it does not, the agent falls back to a fixed path, and ours answers at /.well-known/oauth-protected-resource. Either way it learns where to send you to grant access before it has been granted anything at all.

The third is the list of tools the connection declares once it is open: named actions, each with a description in ordinary English. What that protocol is and where it came from is a longer story. The part that matters here is that those descriptions are prose, and the model reads them the way it reads any other prose.

None of this requires an agent to know about us in advance, which is the point of fixing addresses by convention: "go to this domain and find out what it is" becomes something a machine can do.

The choice is not "which host" but "which way in"

So the agent has an address and has read what is there. Now comes the only real choice in the whole sequence, and it is not between services.

Some tools can read and run things on your computer. Some cannot, because they live in a browser tab or an app. That single difference decides how a connection has to work, and it is the thing our index asks an arriving agent to sort out for itself. The instruction is short:

There are two ways in. Pick by what you can do, not by what you are called: if you can read and run things on the owner's computer, use the local connection; otherwise use the hosted connector.

That is a real line from the file, written by hand, for a reader that is not human. "Not by what you are called" is doing the work: a tool cannot reason usefully about whether it counts as a chat or a coding agent, and it does not need to. It can answer a question about its own capabilities in one step.

The two answers lead somewhere genuinely different. A tool without file access gets a connector address and works on a draft, writing files into it one at a time, showing you a preview link, publishing it by number once you are happy. A tool with file access starts a connection on your machine and works with whole folders instead: it names the folder, the connection uploads the contents, and nothing gets pasted through the conversation.

Both ways in are MCP connections. If your tool also supports Agent Skills, that is a different layer, instructions rather than tools, and it does not replace the connection.

There is a third branch, and most instructions forget it. A tool might read all of this and still be unable to act, because it has no shell and no access to its own settings. The file says what to do then, as an instruction rather than a hope: do not stop, do not hand the problem back to the owner, tell them exactly which screen to open and what to paste, and carry on once they confirm.

Failing usefully is a behaviour you have to ask for. Left alone, a stuck agent apologises.

Where the agent stops and you start

Up to this point the AI agent acted autonomously. Here is where that ends.

The first request that touches your account is refused. Not delayed, not queued behind an approval, but refused, and the refusal comes back carrying a confirmation link and a short code. The agent hands you the link and asks you to open it.

You sign in, if you are not already, with a one-time code sent to your email. The page then tells you which connection is asking and what it will be able to do: your projects, and publishing sites in your name. You approve it or you decline it. Then the agent tries again, and this time it works.

Nothing travels back the other way: no key to copy, no token to paste into the chat, nothing to keep somewhere safe. A tool connecting from a browser or an app follows the same shape, permission granted in a browser, on first use, by you.

That is the two-level decision in full. The agent decided how to connect. You decided whether it may.

Why a refusal is better than a queue

The refused request is not run for you afterwards. Once you approve, the agent has to make the call again itself, which looks like a wasted step and is deliberate.

Permission applies to what happens next, not to what something already tried while you were not looking. If approval could reach backwards and release an earlier request, the thing you approved and the thing that ran would be two events joined by an assumption. Keeping them apart costs one repeated call and buys a straight answer to "what did I actually agree to".

We learned the second half of this the hard way. The rule about which connection suits which tool used to live on our landing page, as a question we asked you to answer before we would show you anything. It was a question about our own architecture wearing the costume of a helpful choice. It belongs in a file that machines read, and that is where it is now. The same admission, pointed at you rather than at the tool, is that you should never have been asked.

What this still gets wrong

Three things, and none of them are close to solved.

A tool can read the instructions and still get stuck. That is why the fallback text exists, and it is a request, not a guarantee. Whether an agent follows it depends on the agent.

More tools means worse choices. This is measured, not folklore. The RAG-MCP paper (Gan and Sun, May 2025) reports tool selection accuracy of 13.62% against a full catalogue, rising to 43.13% when the candidates are filtered down first, with prompt tokens cut by more than half. Both numbers are bad. It is a good argument for connections that do one job with a short, named list of actions, and a poor argument for anything that offers an agent everything at once.

Nobody has to read any of this. The root index is a proposal, not a standard. The one mandatory piece is the authorization metadata, and only for services that speak the protocol at all. A service that publishes nothing is not doing anything wrong. It is just invisible to an agent nobody told about it.

We also cannot tell you how well it works for us. We do not measure requests to the index, so we have no figure for how many agents read it, and a number we have not collected is not one we will quote.

The short version

The mechanics are boring on purpose: text files at agreed addresses, a refusal that carries an address, a capability question with two answers. The shape is what matters. An agent can carry a site all the way from an idea to a live address, and there is exactly one door in that corridor it cannot open. Moving that door, or removing it for a smoother demo, takes away the only guarantee you have.

Frequently asked questions