Six domain MCP servers, and what each lets an agent finish

Our earlier comparison of six custom-domain platforms said that Domainee's MCP server "puts it ahead of most of the category on agent workflows." As of August 2026 that sentence is wrong, and we are correcting it in that post and explaining the correction here. Six vendors now put domain operations in front of an agent over MCP: Entri, Porkbun, GoDaddy, Cloudflare, Domainee, and us. Five of them ship a domain MCP server of their own; Cloudflare's registrar reaches agents through its general Cloudflare API server instead. Three other custom-domain platforms, Approximated, SaaS Custom Domains, and SaaSKevin, publish no MCP server we could find.

One disclosure before the comparison. We build CustomDomain, the sixth server on this list, and this article lives on our blog. Read it with that in mind. Every claim about another vendor comes from that vendor's own public documentation, checked on 19 August 2026, and every vendor is linked so you can check it yourself. Where a vendor does not publish something, we say that instead of guessing.

The servers exist. What differs is what happens when the agent reaches the end of a workflow. On most of them it does not buy the domain and it does not write the DNS record. It produces a link, or a set of records, and a person finishes. Entri's docs say that boundary is deliberate. The others document where the tool stops but not why. That line is what the table below compares.

What a domain MCP server can and cannot finish

Two different jobs get called the same thing. The first is registering a domain the user does not own yet: search, availability, price, purchase. The second is attaching a domain the user already owns: detect where the DNS lives, hand over or write the records, issue a certificate, watch for drift. Registrars do the first, custom-domain platforms the second, and few products cross the line. The agent story differs on each side because the failure modes differ. A bad purchase creates a legal registration and a bill. A bad DNS write can take a company's mail and website down.

An MCP server exposes those operations as tools an agent can call. The tool list tells you the surface area, not whether the agent is allowed to pull the trigger. That is why the tool count is the least useful number in the table below and the last column is the one that matters.

Tool counts and capabilities were read from each vendor's live manifest or public documentation on 19 August 2026. Any price mentioned below is from the same date; check the vendor's site for current pricing before you commit to anything.

1. Entri

Entri's server runs at mcp.entri.com/mcp with OAuth 2.0 client-credentials auth and six tools. Their documentation is unusually direct about the boundary. On the purchase flow it says the AI agent "must present the link to the user and ask them to complete the purchase," and that "the purchase is completed by the user in the registrar's checkout — the agent cannot complete it on their behalf." The same wording appears for connecting a domain: the agent must present the returned link, and cannot complete the DNS setup on the user's behalf. This is a link-producing server, on purpose.

There is also no side door. Entri's overview notes that if no sharing registrar is configured, the domain tools return an error rather than falling back to some other path.

2. Porkbun

Porkbun ships a first-party server you run with npx -y @porkbunllc/mcp-server. The server exposes 61 tools, and its README states that write operations automatically attach a per-call Idempotency-Key header, with retries inside 24 hours returning the cached response so an agent can retry a network error "without double-charging or double-registering."

The more interesting part is underneath. Porkbun's REST API, at version 3.15, documents a dryRun flag on billable and destructive writes, machine-readable errors carrying a next_action object, per-key IP and domain scoping, X-RateLimit-* response headers, and a free sandbox with separate pk1_sb_ keys plus a mock server that needs no credential at all. GET /domain/getRegistrationRequirements/{tld} returns the registration payload for a TLD as JSON Schema, the shape an agent needs to fill a form it has never seen. Porkbun does not state whether the MCP server itself permits unattended completion, but it is the only vendor here that has built the recovery machinery the question depends on.

3. GoDaddy

GoDaddy's MCP server is the most conservative of the six, and it is explicit about why. Its documentation lists the limitations in plain terms: "Read-only: The MCP server cannot register domains, modify DNS records, transfer domains, update account settings, or make purchases," and "No authentication: Current tools use public domain data and do not accept GoDaddy account credentials." The availability-check and search tools work without a credential, so an agent can check a name against GoDaddy before you issue it anything. GoDaddy does not publish a tool count for the server.

That boundary is deliberate, and GoDaddy names the alternative: for domain purchase or DNS management from an agent, its docs point you at the gddy CLI agent skill, driven by your own authenticated credentials. That is a separate surface from the MCP server, as is the v3 REST API, which uses Bearer personal access tokens across eleven granular Domains scopes, rate limits at 60 requests per minute per credential, and requires a valid billing method on file or a funded Good as Gold balance for paid operations. Note for anyone with older code: the classic sso-key header is marked deprecated, supported through 2026 on older APIs, and does not work against v3 endpoints.

4. Cloudflare

Cloudflare's domain tooling reaches agents through its general MCP server rather than a domain-specific one, because the registrar is part of the Cloudflare API. The constraint is on the registrar side, and Cloudflare states it plainly: the Registrar API, announced in April 2026, is in its first beta release, only a subset of supported Cloudflare Registrar extensions is available through it, unsupported ones return extension_not_supported_via_api, and renewals, transfers, and contact updates are not yet available through the API. So an agent can search, check, and register within the supported set, and then stops. Registration pricing is at cost, meaning the registry's own registration and renewal fees.

5. Domainee

Domainee publishes an MCP server with 11 tools, authenticated with the same Bearer token you use for its REST API and minted at /developers. Its Buy a Domain API covers more than 500 TLDs at wholesale price plus a flat $1 fee, with the end user as the legal registrant.

Domainee draws its line in the opposite place from Entri. Its DNS and connection tools act directly, including create_domain, update_domain, and delete_domain, while purchase is held back. Its docs say the Buy-a-Domain API was "deliberately kept off the v1 MCP tool surface," and that buy-a-domain "ships in MCP later, with a confirmation step the agent must surface to a human." That is a boundary chosen on purpose, not a gap.

This is the vendor whose MCP we previously called category-leading. Its 11 tools are unchanged. Five other vendors have shipped a server since.

6. CustomDomain (that is us)

Ours is a streamable-HTTP server at mcp.customdomain.ai/mcp, OAuth 2.0 client credentials, protocol version 2025-06-18, registered in the official MCP registry as ai.customdomain/mcp version 0.4.0 since 12 July 2026. There is also a stdio transport, so it can run locally rather than hosted. Twelve tools. Product detail is on our MCP server page, and our guide to connecting domains with AI agents walks through the same flow step by step.

Ten of our twelve MCP tools never write DNS. They return the records for the user or their platform to apply. The tool descriptions say so in the manifest itself: connect-domain and forward-domain both end with "Never writes DNS directly," and discover-provider is marked "Read-only; writes no DNS." add-email is the same shape: it returns the MX, SPF, DKIM, and DMARC records to add, plus a one-click authorize link when the domain's DNS provider supports one. Two tools do act, reapply-connection and disconnect-domain, and they act only through a durable grant, which one rail stores: Domain Connect async, where the customer authorizes at their own DNS provider. Both fail if the connection is not in a managed state, and most of ours are not.

On the purchase half we are in the same position as Entri, and we should say so. create-domain-order returns an orderId for a direct registrar and a checkout link for a sharing registrar, and the link is opened by a person. Every paid order first passes an authorization callback to the integrator that denies by default when it is not configured, purchase sits behind its own kill switch that ships off, and the host application mounts the payment UI and calls fulfill itself, because that UI cannot live in a self-contained widget bundle.

Comparison at a glance

Why a link handoff is not laziness

Registering a domain creates a legal registrant. ICANN contact data has to be accurate, the registration is a contract, and money moves. A registrar that lets an unattended agent complete that transaction accepts a category of dispute a link handoff avoids. We have not solved this either. Our Sell surface carries name, email, and country for the buyer, and full ICANN and WHOIS contact handling is out of scope for the current cut.

Writing DNS at a customer's provider is the other half. A credential with write access to someone's zone can remove their MX records and their website in one call. Every product that automates the DNS step holds, however briefly, a key that can take a business offline. The reasonable designs either scope that credential to a single write and discard it, or never hold it at all and hand the records to a human.

We took the first option, and it has a cost we should state. Our OAuth connections are use-once. No provider adapter requests a refresh scope, and the callback decodes only the access token, discarding any refresh token unparsed. The token stays on one stack frame, performs one record write, and is gone. That is good for blast radius and bad for self-healing.

If a customer's records later drift, reapply-connection only works on a connection we hold a durable grant for, and the only rail that stores one is Domain Connect async. Everything else comes back not-managed: the six providers we reach by OAuth (Cloudflare, DigitalOcean, DNSimple, Netlify, Vercel, and WordPress.com), the seventeen we reach with a customer's own API token, and the thirty-eight we guide by hand. Our monitor detects the drift and emits a domain.record_missing webhook for a human to act on. It does not heal it. Closing that gap needs code, not a configuration change, and we have not written that code yet.

None of the six documents an unattended path all the way through a purchase or a DNS write. Some stop at a link, some stop at a record list, and Porkbun's registrar API is the one built with the error-recovery and dry-run machinery that going further would need.

What to ask before you wire an agent to a domain vendor

• At which exact step does the tool stop and require a human? Ask for the tool description text, not a sales answer.
• Is there a sandbox, and does it need a credential? Porkbun runs a free sandbox on separate pk1_sb_ keys, plus a mock server that needs no credential at all.
• Are writes idempotent, and is there a replay window? An agent that retries a purchase without an idempotency key is a billing incident.
• Is there a dry-run mode on anything that spends money or changes DNS?
• Do errors carry structured recovery information, or just a string? An agent cannot act on prose.
• If the vendor holds a credential for the customer's DNS provider, how long does it hold it, and what can it do with it after the initial write?
• What happens 90 days later when the records drift? Does anything reapply them automatically, or does a webhook wake up a support engineer?

If you are evaluating the API underneath the agent tools, our custom domain API page covers the endpoints, and Domain Connect explains the one open standard here that removes the credential problem by keeping the write inside the DNS provider's own interface.

The bottom line

Across all six, an agent can search and check availability without a human. Entri says in its own documentation that it cannot go further. GoDaddy's MCP server is read-only by design and accepts no account credentials. Cloudflare's registrar beta cannot renew, transfer, or update contacts. Domainee lets its DNS tools act and holds purchase back on purpose. We relay DNS records rather than writing them, our sharing-registrar purchases return a checkout link a person opens exactly like Entri's, and we can only reapply a drifted record on connections made through Domain Connect async, which is a small minority of ours. Only Porkbun publishes the idempotency keys, dry-run flag, and sandbox that make letting an agent finish a billable call defensible.

If you are building agent-driven domain onboarding yourself, the server is the easy part and the boundaries you can defend are what people integrate against. Our Starter tier includes 10 domain connections a year with the full REST API and webhooks, and every tier is on our pricing page. What we built for AI agents covers the design in more detail, or start on the free tier and point an agent at the server yourself.