customdomain-mcp

Endpoint

Hosted endpoint · transport streamable-http

Connect

This is a remote MCP server — point an MCP client at the endpoint URL. Clients with native remote support (Claude, Cursor, VS Code, …):

For stdio-only clients (older Claude Desktop, etc.), bridge with mcp-remote:

If the server requires authentication, add the provider's token/header (e.g. an X-API-Key) per its docs. A quick reachability check:

Tools

• search-domain-availability — Check whether a domain is available to register, with real-time price and renewal price. Use before create-domain-order when a user needs a new domain.
• generate-domain-suggestions — Generate available-to-register domain suggestions for a set of keywords, each with real-time price and renewal price. Only available domains are returned; the top pick is marked.
• create-domain-order — Start a domain registration/purchase through the resolved registrar. This spends the user's money and cannot be undone from here, so ask the person first and repeat the domain they confirmed in confirm_domain; a confirm_domain that does not match domain orders nothing. Enterprise/direct registrars return an orderId; sharing registrars return a checkout link and jobId to poll. The purchase is also authorization-gated on the integrator's side. After the domain is registered, use connect-domain to point it at the user's app.
• connect-domain — Attach a domain the user already owns to their app and set it up to serve. Returns the authoritative DNS records to add in the records field: a CNAME/A to the CustomDomain™ edge, which serves the domain with automatic HTTPS, or, when the app routes domains to its own infrastructure (a connect target), a CNAME/A to that infrastructure, which serves it, a link for the user, a linkKind and a jobId to poll with check-connection-status. linkKind says what the link is and who opens it: domain_connect is a one-click authorization at the user's DNS provider, which the user opens; guided_setup is a single use setup page for this one domain that the user opens with no account, which the control plane issues only to an API key or a client credentials token and only for a domain no end user of the platform connected; console opens the workspace console and needs a workspace login, so it is for a member of the workspace and not for the user, and it is the only link an agent token gets: give the user the records instead. A guided_setup link is a bearer link that lasts 30 days and lets whoever opens it first set up the domain, so send it only to the person who owns the domain. consoleLink is the console page when link is another kind. Read the message field, which says which one you got and whether the provider instead offers a sign-in rail. Relay the records to the user; never writes DNS directly.
• check-connection-status — Read the live status of a domain connection by its connectionId (the jobId connect-domain returned is the same id), and get the authoritative DNS records to add in the records field. Key completion off the boolean connected:true (the reliable terminal signal); the status string is one of pending, propagating, live, failed. Poll this until connected is true (usually under a few minutes once records are in place). When a connection failed, errorCode says why. managed:true means the platform holds a durable grant for this domain, which reapply-connection uses to heal it server-side. managed:false does not mean a repair needs the user at their DNS provider: reapply-connection also works through a DNS zone CustomDomain™ hosts for the domain and through a connected provider account that keeps it (list-connections shows dnsHosting, list-provider-accounts the accounts), and find-saved-access then use-saved-access writes the records with a saved key. Only where none of these holds does a repair need the person to add the records at their DNS provider or to sign in again through the link connect-domain returns.
• check-order-status — Read the live status of a domain order by orderId (enterprise) or jobId (sharing). Provide exactly one.
• reapply-connection — Re-apply a connection: the control plane recomputes its desired DNS records from stored config and rewrites them through the access CustomDomain™ keeps for the domain. That access is the stored grant of a managed connection (managed:true), a DNS zone CustomDomain™ hosts for it (dnsHosting hosted on list-connections), or a connected provider account that keeps the domain and wrote its records (list-provider-accounts). Use this to self-heal a domain that has drifted or fallen out of live. Never supply records; they are recomputed server-side. Answers conflict when none of those holds: check first rather than using this to probe, and then repair with find-saved-access and use-saved-access, or have the person add the records at their DNS provider or sign in again.
• disconnect-domain — Disconnect a domain: the control plane reverts its DNS through the stored grant, then deletes the grant and connection. This takes the domain offline and cannot be undone here, so ask the user first and send the domain they confirmed in confirm; a confirmation that does not name the connection's domain disconnects nothing. Needs the domains:disconnect scope, which is separate from connecting. Never supply records; the revert is computed server-side.
• discover-provider — Detect where a domain's DNS is hosted and which ways can set it up: Domain Connect, a sign in at the DNS provider (OAuth), a secure sign in, an API key, the records by hand, or DNS hosting. Read-only; writes no DNS. rails says per way whether it can run for this domain: domainConnect and oauth are the one-click and the sign in ways; secureSignIn is the sign in a person does at their provider in a window CustomDomain™ runs, where they approve the changes, and it may keep a lasting API key (key says what rights it has and when it ends); apiKey and manual are a key the person makes and the records by hand; dnsHosting is the application's offer to host the domain's DNS by moving its nameservers (verdict offered, offered_first, recommended or unavailable; migrate-nameservers does it, and an agent may only while the application's DNS hosting is on). A person takes secureSignIn in a browser, never an agent: for an agent it reads available:false with reason caller_cannot_start even where the provider offers it, which is not a missing way, so hand the person the connect-domain link (linkKind guided_setup or console) to take it. recommendedRail names the server's pick as the control plane does: oauth, domain_connect, cloud_browser (secure sign in), api_key, manual or saved_access. Use it before connect-domain / forward-domain / add-email to see whether the domain can be configured in one click or needs the user to add records manually. It also returns the pre-flight advisories: recordConflicts lists live records that clash with the ones the connect would write (tell the user to clear them first), willFallbackToManual warns that the provider stops writing automatically past conflictTolerance conflicts so the one-click rail would quietly become a manual record list, a recordConflicts entry of kind caa-blocks-letsencrypt means the domain's CAA record would block HTTPS issuance until Let's Encrypt is authorized, and a non-empty apexMessage means the provider cannot host the record a root domain needs, so connect a subdomain instead. A recommendedRail of saved_access means the workspace already keeps a provider key that may act for the domain (rails.savedAccess): use find-saved-access and then use-saved-access (rails.savedAccess.use says how) rather than starting a new sign in. Report these before asking the user to authorize anything.
• forward-domain — Forward (permanent 301 redirect) a domain to a destination URL or host. When the domain's DNS provider supports one-click (Domain Connect) setup, returns a link for the user to authorize at their provider; otherwise returns the DNS records to add in the records field plus a console link with the same guided setup. Either way returns a connectionId to poll with check-connection-status. Never writes DNS directly.
• add-email — Set up a domain to send and receive email with correct authentication (MX, SPF, DKIM, DMARC) so mail is delivered and not spoofed. Ideal for an email platform onboarding a customer's sending domain. Pass provider (google, microsoft365, or zoho) to auto-fill the standard MX and SPF and supply only the DKIM values your platform generated, or set each field manually. Uses server-side record templates; supply settings, never raw DNS records. Returns the records to add in the records field, a one-click authorize link when the domain's DNS provider supports it (a console link with the same records otherwise), and a connectionId to poll.
• list-connections — List the domains connected across the account so an agent can inventory, monitor, and reconcile a whole portfolio, not just the one job it started. Returns each connection's domain, connectionId, live status, connected flag, setup type, managed flag, and dnsHosting (who runs the domain's DNS: state none, moving, hosted or failed). Optionally filter by status (pending, propagating, live, failed), or by dnsHosting to find the domains CustomDomain™ hosts: hosted, moving, or any. Read-only. Pair with reapply-connection to heal any that are not live. A row can be re-applied when it has managed:true, when its dnsHosting is hosted, or when a connected provider account keeps it (list-provider-accounts), so check those first instead of calling reapply-connection to find out.
• check-certificate-status — Read the HTTPS certificate of a connected domain: issuer, expiry, days left, whether renewal is failing and the last error. Certificates renew on their own. attention is empty when nothing needs a person, else failed, renewal_failing, expired or expiring. Read-only.
• recheck-connection — Re-run a connection's DNS check now instead of waiting for the next scheduled one: a failed connection re-enters verification, a live one is checked for drift. Returns which records resolve and the new status; poll check-connection-status for the outcome. Writes no DNS. Use diagnose-connection first to see what is missing, and recheck once the user has fixed it.
• diagnose-connection — Explain, record by record, what public DNS shows for a connection and what the user still has to do: each record is found, missing or mismatch with what DNS answers today, plus the issues that explain it (a hostname typed in the Name field, a proxy in front, a leftover record). Read-only; never changes the connection.
• check-billing-status — Check whether the workspace may connect new domains right now. When it may not, restricted is true, code is billing_required and details say where an owner or admin fixes billing. Also returns the plan and this month's usage. Read-only. Use it after a billing_required failure or before a batch of connects.
• list-domain-orders — List the domain purchases made through the account, newest first: each order's status, domain, registrar and the checkout link when there is one. Read-only. Use check-order-status for one order.
• check-nameserver-status — Read the nameserver move of a connection's domain: its state (pending, copying, needs_review, needs_dnssec_off, waiting_ds, setting, propagating, active, failed, rolled_back), the registrar where they change, the old and new nameservers, what the registry lists now, what it waits on and the next step for a person. done is true once it is active, failed or rolled back. Read-only.
• migrate-nameservers — Move a connected domain's nameservers to the application's DNS host, so its records are hosted and kept correct from then on; an agent may do it only while the application's DNS hosting is on. The domain's records are copied first, mail included. DNSSEC is turned off first when it is on. This changes who answers for the whole domain, so ask the person first and send confirm: true. The nameservers change through a connected registrar account (providerAccountId), the person's own sign in in the cloud browser, or by the person at the registrar: the result's nextStep says which. Never send a registrar key. While DNS hosting is off every call of this tool is refused (error ns_not_offered), even one that would carry on a move a person started, and nothing is changed: do not retry it, and tell the person they can turn DNS hosting on in the application's settings, or that the platform can start the move with its API key. rollback-nameservers is not refused. Poll check-nameserver-status until done is true.
• rollback-nameservers — Move a domain's nameservers back: to the ones it had before the move (target previous), or to its registrar's own DNS (target registrar_default). Without a target it goes to the old nameservers while they still answer for the domain, else to the registrar's DNS (rollbackDefault says which). With a connected registrar account it happens now; otherwise nextStep says what the person sets or chooses at the registrar. Ask the person first and send confirm: true.
• list-provider-accounts — List the provider accounts (saved keys at a DNS host or registrar) the workspace has connected: each one's accountId, provider, label, how it was made (api_key or secure_sign_in), whether it is kept (continuous) or used once, the domains it covers, its status and the domains linked to it. The accountId is what migrate-nameservers takes as providerAccountId and use-saved-access takes as accountId. With domain it keeps the accounts that may act for that domain, best first, and savedAccess says for each whether its access already holds the domain. Never returns a key. Keys your customers made at their own sign in are left out (endUserKeys counts them). A delegated agent token sees only the keys that serve its own application, with that application's connections and without the domains another application of the workspace has connected. Read-only.
• find-saved-access — Find the saved keys that may write a connected domain's DNS records, best first: each one's accountId, provider, label, how it was made, and ready (its access already holds the domain's zone) or not ready (a read with the key showed it reaches the zone, and using it adds the zone to its access). Use it before starting a new sign in or asking the person for a key. An empty list means none may act for this domain. Never returns a key, and never one a customer made at their own sign in. At most 3 keys are read at their provider to check they reach the domain. Read-only; use-saved-access uses one.
• use-saved-access — Write a connected domain's DNS records with a saved key and link the key to the domain, so later repairs and the removal use it. This changes the domain's live DNS through the person's own account at their provider, so ask the person first and send confirm: true. Take accountId from find-saved-access for the same connection; any other account is refused (saved_access_not_usable). The records are the ones the connection already holds: you supply none. A key that is not ready adds the domain's zone to its access once the records are written. A write that fails links nothing and leaves the key's access as it was, but the provider may have changed some of the domain's records before it failed (saved_access_write_failed, with the provider's words): tell the person, then try again. Then poll check-connection-status.

About MCP

The Model Context Protocol (MCP) is an open protocol Anthropic introduced for connecting LLM-based agents to external tools and data sources. Providers publish MCP servers that expose their API surface as structured, discoverable tools — an MCP-compatible client (Claude Desktop, Cursor, Cline, Continue, etc.) can connect to the server and call its tools without any per-provider integration code.

Browse every MCP server on the APIs.io network or compare with the broader Agent Skill surfaces of the same providers.

Work with this as data

Every MCP server here is available over the APIs.io API and to AI agents over MCP.

curl "https://apis.io/api/v1/mcp/customdomain-mcp"

curl "https://apis.io/api/v1/mcp?limit=25"