MCP servers

One server, one customer, one name

A server that boots for a customer registers its address and comes up on its own hostname with its own certificate. Nothing about the customer has to exist first: no domain bought, no zone delegated, no record added by hand before the server can answer.

A hostname is a domain to itself as far as browsers and certificate authorities are concerned, so one customer's certificate budget, cookie origin and reputation are not the next customer's. On a plan that holds several domains you also choose which customer sits on which one.

Moving a server nobody told you they kept

The address is not in the hostname, so moving a server between machines, regions or providers is a PUT. Every client that already holds the URL keeps working, and you do not have to find out who they are first.

This is the part that is easy to get wrong early and expensive to fix later. A URL handed to a client is not revocable by asking, and a name derived from the address is a migration that requires every holder of it to act.

Advertising it in DNS

There is an IETF draft that advertises an MCP server in a TXT record at _mcp under a domain, carrying the endpoint, the transport, a key and a capability profile, so a client can bootstrap from a resolver cache instead of an HTTPS round trip. It asks for no new record type, so the DNS half works here today: POST a TXT record named _mcp on a hostname you hold and it is served. It is a draft rather than an RFC, and standards tracks where it has got to.

The server we run

Separate from anything above: we operate an MCP server of our own at /mcp, so an agent can mint a hostname, repoint it and diagnose it mid-task rather than needing a person to have written the config first. The tool list is open; the calls need a credential.