Guide

How to let AI agents connect domains (MCP)

AI agents that build or deploy products for people increasingly need to find, register, and connect a domain without a human clicking through a DNS panel, and the Model Context Protocol (MCP) is the standard way to expose those capabilities to an agent. This guide explains what a domain provisioning flow looks like when an agent runs it end to end, and how Custom Domain packages that flow as MCP tools an agent can call.

Why agents need domain provisioning

When an agent builds a landing page, spins up a storefront, or ships a small app for a user, the last step is almost always a real address on the open web. Until recently that meant handing the user a checklist: buy a name somewhere, log into a registrar, find the DNS tab, paste in records, wait, then come back and confirm. Every one of those steps is a place the user drops off, and none of them are things an agent could do on its own.

Giving an agent the ability to search, register, and connect a domain closes that gap. The agent can go from an idea to a working, HTTPS-secured address in one continuous run, and the person it is working for never has to touch a DNS record. For a platform that hosts many such projects, this is also how you let AI-driven onboarding actually finish the job instead of stalling at the domain step. See Custom Domain for AI agents for the audience view of this.

What the agent needs to do

A complete domain provisioning flow breaks into three jobs. An agent needs each one exposed as a callable capability so it can chain them without human help.

Search for a domain

First the agent needs to find a name that is available and appropriate. That means checking availability for a specific name and, ideally, getting suggestions when the obvious choice is taken. A good search capability returns availability and price so the agent can present real options to the user or pick one against a budget it was given.

Buy or register it

Once a name is chosen, the agent registers it. Registration is a real transaction with a registrar, so this step usually needs an account and a payment method already on file, plus the contact details a registrar requires. Exposed as a tool, registration lets the agent turn an available name into an owned one in a single call, rather than sending the user off to a checkout page.

Connect it to the product

Owning a name is not the same as pointing it at your product. Connecting a domain means three things happen: DNS records are written so the name resolves to the product, ownership is verified, and a certificate is issued so the address serves over HTTPS. In plain DNS terms this looks like adding a CNAME on a subdomain such as app.example.com that points at the target your platform gives you, adding a TXT record to prove ownership, and letting a certificate be issued over ACME. For an agent, the win is that a single connect capability can carry out all of it and report back when the address is live and secure. If the domain is registered through the same flow, the DNS records can be written automatically with no manual paste at all. The certificate side is what we call on-demand TLS: certificates are provisioned and renewed for each connected domain without anyone managing them by hand.

How MCP exposes these as tools

The Model Context Protocol is an open standard for connecting AI agents to external systems. An MCP server advertises a set of tools, each with a name, a description, and a schema for its inputs and outputs. The agent reads that list, decides which tool fits the step it is on, and calls it with structured arguments. The protocol handles the request and returns a structured result the agent can act on.

This maps cleanly onto domain provisioning. Search, register, and connect each become a tool. The agent that is searching for a name calls the search tool, reads the availability back, calls the register tool on the name it picked, then calls the connect tool to attach the name to the product and wait for HTTPS to come up. Because the tools are described in a machine-readable schema, the agent chooses and sequences them on its own, which is exactly what lets a domain flow run without a human in the loop.

How Custom Domain provides this to agents

Custom Domain is fully managed infrastructure for bringing custom domains onto a product, and it exposes the same capabilities over MCP so an agent can drive them directly. The agent can search for a domain, register it, and connect it, with DNS records written for the user, ownership verified, and a certificate issued at the edge, all without the user ever opening a DNS panel. The provisioning logic is the same one that powers the product, so what an agent does through MCP and what a platform does through the API stay consistent.

This is a greenfield category, and the shape of it is still being written. Rather than restate a tool schema that will keep evolving, the exact MCP endpoint, the tool names, their parameters, and how an agent authenticates are documented in one place. See the docs for the current MCP details, and the pillar guide on custom domains for SaaS for how the same infrastructure serves platform teams building this into their own product.

Frequently asked questions

What is MCP and why does it matter for domains?

MCP, the Model Context Protocol, is an open standard for connecting AI agents to external tools. It matters for domains because it gives an agent a machine-readable way to discover and call the exact capabilities, search, register, and connect, that a domain flow needs, so the agent can run the whole flow itself instead of handing steps back to a person.

Can an agent register a domain on its own?

Yes, when registration is exposed as a tool the agent can call it. Because registration is a real transaction, it relies on an account and payment method being set up in advance, along with the contact details a registrar requires. Once those are in place the agent can turn an available name into an owned one in a single call.

Does the user still have to edit DNS records?

No. The point of an agent-driven connect flow is that DNS records are written for the user, ownership is verified, and a certificate is issued automatically. If the domain is registered through the same flow, no manual record editing is needed at all.

How does HTTPS get set up without a human?

Certificates are issued over ACME, the standard protocol for automated certificate issuance, and provisioned and renewed per domain without anyone managing them by hand. This is what we mean by on-demand TLS, so a freshly connected address serves securely as soon as it goes live.

Where do I find the exact MCP tools and endpoint?

The current MCP endpoint, the available tools, their parameters, and the authentication details live in the docs. Because this is a fast-moving category, the docs are the source of truth rather than any fixed example here.