THE DOMAIN STEP, AS TOOL CALLS

Let the agent connect the domain, safely.

An agent that builds and ships a whole site should not stall on the last step and hand a human a CNAME. Through a hosted MCP server and REST API, your agent searches availability, buys or brings a domain, and connects it end to end. Every call passes the same ownership and certificate gates a person passes.

Create account Read docs

Hosted MCP server, no wrapper to write. Scoped keys you can revoke. A webhook on live.

See the MCP tools →

mcp · tool call

// tool: domains.connect domains.connect({ hostname: "app.customer.com" })

result

{ "id": "cxn_3f2c9a", "provider": "cloudflare", "state": "pending_ownership", "poll": "domains.status(cxn_3f2c9a)" }

pending_ownership → verifying → live webhook fires on live.

25+ DNS providers, auto-detected · Ownership verified before anything serves · 3 deterministic states · Webhook on live · Scoped, revocable keys

The problem, for you

An agent can ship a whole site, then stall on DNS.

Your agent writes the code, provisions the hosting, and deploys. Then the task hits the one step it cannot finish. Custom-domain setup was built for a person with two browser tabs open: copy a record from one, paste it into a registrar in the other, guess right about the host field and the trailing dot. An agent has no tabs.

So the run ends with "now go add this CNAME", a hand-off that breaks the autonomy you were selling. Bolting a browser-driving agent onto the DNS panel is worse: an unverified actor clicking around someone’s registrar, with no gate on which domain it is allowed to touch.

The domain step is programmable. It just needs an interface built for a caller that isn’t a person, with the safety rails kept on.

1 call

replaces the manual DNS hand-off. The agent passes a hostname and polls a state, instead of pausing the run to wait on a human.

0

browser tabs in the loop. No registrar UI to drive, no screen to scrape, no clipboard step to get wrong.

How it works for you

Search, buy, connect, as tool calls.

01
Find and acquire. The agent searches availability and buys, or brings a domain the user already owns. One call each, no console.
02
Connect in one call. Pass the hostname. We detect the provider and write the records via a provider grant, a bring-your-own API token, or a signed provider-hosted one-click setup handed back for the user to approve.
03
Ownership is proven first. Verification and certificate issuance are the same gates a human passes. An unverified hostname never gets a certificate and never serves.
04
Poll a deterministic state. Status moves through three states and a webhook fires on live. Simple to reason about, easy to resume after an interruption.

records · app.customer.com

TYPE

NAME

VALUE

TTL

CNAME app.customer.com edge.customdomain.ai 3600 TXT _cd.app.customer.com cd-verify=cxn_3f2c9a 3600

We detect the provider, write these records, then verify the TXT before issuing HTTPS. The agent never assembles a record by hand.

pending_ownership → verifying → live

What you get

A surface built for a non-human caller.

A hosted MCP server

Domain tools your users’ agents call directly: search, buy, connect, check status. No wrapper for you to write, no server for you to run.

Machine-readable by design

A served OpenAPI 3.1 spec and an llms.txt, so an agent can discover the whole surface without a human reading docs.

Deterministic states

Every connection reports one of a small set of states, so an agent can branch, retry, and resume without guessing what happened. A webhook fires the moment a domain goes live.

Scoped, revocable credentials

The MCP server authenticates with a scoped key you issue and can revoke. An agent’s reach stays bounded, attributable, and auditable per call.

Discoverable

Your agent reads the surface itself.

Point an agent at /llms.txt and it finds the tools, the endpoints, and the state machine on its own. The same connection you started with one call resolves to a signed webhook the moment it is live, so a paused run can pick up exactly where it left off.

MCP server docs → Webhook events →

GET /llms.txt

# Custom Domain # Connect a custom domain end to end. tools: domains.search, domains.buy, domains.connect, domains.status spec: /openapi.json (OpenAPI 3.1) states: pending_ownership | verifying | live

webhook · connection.live

{ "event": "connection.live", "id": "cxn_3f2c9a", "url": "https://app.customer.com" }

Provider coverage

Whatever host your user is on, detected.

The agent never has to know the provider. We fingerprint it from the hostname and write the records the right way for that host.

Cloudflare

Route 53

Google Cloud DNS

Azure DNS

GoDaddy

Namecheap

Vercel

Netlify

DigitalOcean

Porkbun

Name.com

IONOS

25+ providers auto-configured. Where a provider cannot be automated, the connection still returns exact records for the agent to hand back. Logos are the property of their respective owners and shown to describe interoperability.

The rails stay on

An agent passes exactly the gates a human does. Ownership is verified before any domain goes live, and a hostname that isn’t authorized never gets a certificate and never gets served. Certificates issue in the TLS handshake and renew themselves. Drift is caught hourly. The rails stay on whether the caller is a person or a program.

Read our security model → For site builders →

Questions

Can an agent connect a domain end to end?

Yes. Through the MCP server and REST API an agent can search, buy, and connect a domain, then poll status to live. Where the user must approve, we hand back a signed provider-hosted one-click setup instead of blocking the run.

What stops an agent connecting a domain it shouldn’t?

The same ownership verification a human faces. An unverified hostname never issues a certificate and never serves, so an agent cannot connect a domain the user doesn’t actually control.

How does the MCP server authenticate?

With a scoped API key you issue and can revoke at any time. Every call is attributable to that key, so an agent’s access is bounded, auditable, and easy to shut off.