Naming a company is a conversation, and one side of that conversation is now often a model. The expensive part is the tab switching: you think of a name, leave the chat, type it into a search box, read the result, come back, and lose the thread you were on. An MCP server removes the switch. This post covers what ours exposes, where its answers come from, how to connect a client in about a minute, and the two ways the data can be wrong.
What an MCP server is
Anthropic published the Model Context Protocol on 25 November 2024 as "a new standard for connecting AI assistants to the systems where data lives". The specification is deliberately unglamorous: JSON-RPC 2.0 messages passed between a host application, a client inside it, and a server that exposes tools. The model picks the tool and the arguments. You write a sentence.
For a naming session the useful part is state. A server can hold the extensions you actually register under, the shortlist you have been building for a week, and what you already searched, so an assistant starts from your context instead of from nothing.
How the domain search MCP server works
The server answers at https://domaingenerator.co/api/v1/mcp over streamable HTTP, the transport the spec defines for remote servers: "Every JSON-RPC message sent from the client MUST be a new HTTP POST request to the MCP endpoint". Open that address in a browser and it answers without any credentials, listing what it is, which tools it offers and what the limits are. That page is the quickest way to tell a server outage from a client config you typed wrong.
Availability comes from a list, not a lookup
Most domain MCP servers resolve one name at a time over the network. The mcp-domain-availability server does DNS resolution, then a WHOIS query, then a socket connection as a fallback, across "50+ TLD extensions", with concurrency capped at 20 and a warning in its own docs that "large bulk checks may hit rate limits from DNS/WHOIS services".
This one works from the other end. We keep our own copy of what is already registered, rebuilt every day from the registry zone files: 300M+ names across 1,000+ extensions. A check reads that copy rather than asking the network about each name, which is why a single call can cover the whole catalogue instead of a dozen popular endings, and why the answer comes back in milliseconds.
That is the whole design argument. Asking about one name across every extension we track costs roughly what asking about a dozen does.
Two ways the answer can be wrong
No availability tool is exact, and this one drifts in two known directions. The list is at most a day old, so a name someone registered this morning can still read as available. And a check that cheap trades a little precision for its speed: a small share of names come back as taken when they are in fact free. Neither is fixed by asking again. Confirm at a registrar before paying, particularly since the same domain costs wildly different amounts at different registrars.
The assistant and the website are the same account
Every tool runs the check the website already runs, against the same data and the same account, so nothing here is a second implementation with its own caps and its own bugs. A name saved from a conversation is in your library when you next open the site. A favourite extension set in the browser changes what the assistant checks by default.
What the domain search MCP server does
One tool finds names. The others exist to aim it and to keep what it found.
| Tool | What it does |
|---|---|
search_domains | Checks names against a set of extensions and splits them into available and taken |
check_usernames | Checks a handle on X, YouTube, TikTok, Snapchat, Pinterest, Discord, GitHub, Telegram and Twitch |
generate_domains | Runs a keyword through the naming generators and returns candidates with availability already resolved |
list_favorite_tlds, add_favorite_tld, remove_favorite_tld | Read and edit the extensions the account cares about, which become the default search set |
list_saved_domains, save_domain, remove_saved_domain | Read and edit the shortlist shared with the website |
get_recent_searches, get_recent_generations | Read what this account looked at on the site, so a session can be picked up rather than restarted |
Two details in that table are easy to skim past. generate_domains uses no model at all: it is lexical and deterministic, so the same keyword returns the same candidates every time, which is what makes it worth calling from something that is already a model. And check_usernames splits its answer four ways rather than two, because no platform publishes a list of taken handles and each one has to be probed live. A platform that blocked or timed out comes back as unknown, never as free.
Every tool takes a batch rather than one name at a time, and the batch sizes are written into the tool descriptions your client already reads. The history tools read only. Searches you run through the assistant are not written back into it, so what you see there is what you did on the site.
How to use it
Two steps: sign in, then write one line into your client. Every tool needs an account, search included. The server connects as a person and attributes each call to them, so there is no anonymous mode to fall back on.
Claude Code takes a command, and opens the browser itself:
claude mcp add --transport http domain-generator https://domaingenerator.co/api/v1/mcpClaude Desktop takes only the URL: Settings, then Connectors, then Add custom connector, paste, approve. Everything else wants a JSON or TOML entry, and the clients disagree about what the address field is called. That disagreement is where most of the lost twenty minutes goes:
| Client | Where the entry goes | What it calls the address |
|---|---|---|
| Cursor | ~/.cursor/mcp.json | url |
| VS Code | .vscode/mcp.json | url, under a servers root rather than mcpServers |
| Windsurf | ~/.codeium/windsurf/mcp_config.json | serverUrl |
| Gemini CLI | ~/.gemini/settings.json | httpUrl, because url means the older SSE transport |
| Cline | cline_mcp_settings.json | url, with type: streamableHttp |
| Codex CLI | ~/.codex/config.toml | url, or let codex mcp add write it |
The connect page writes the exact snippet for whichever of those you pick, with your key already in it if you chose that route.
Two ways to authenticate
A client that speaks OAuth needs nothing from you but a click. It discovers the authorization server from the endpoint, opens a browser, and you approve the connection on a consent screen. The spec makes that flow specific: clients "MUST implement PKCE" and servers must publish OAuth 2.0 Protected Resource Metadata, which is what turns a bare URL into a working connection without anyone pasting a secret.
For a script, a server, or a machine you share, mint a key in your settings instead. Keys are prefixed dgmcp_, sent as Authorization: Bearer, and shown exactly once. You can hold a few at a time, and revoking one takes effect within about a minute.
Rate limits
Limits are counted per account rather than per key, so a second key does not buy a second budget. They sit well above what naming actually costs: a session that generates forty candidates and checks each across your favourite extensions is two calls, not forty. The current numbers are on the connect page, and the endpoint reports them to anyone who asks.
What a session actually looks like
The prompt that works is the one you would say to a colleague: describe the business, name the constraint, and let the tools run. "I'm launching a plant care app, find me something short that is free in .com, .io or .app, and check the handle is free on GitHub and X too."
What happens next is four tool calls. generate_domains turns the description into candidates. search_domains checks all of them against those three extensions in one pass. check_usernames takes the survivors and probes the two platforms you named. save_domain keeps the two you liked, and they are in your library the next time you open the site in a browser.
The part that is hard to appreciate until you have done it is the follow-up. "Too cute, try again without the -ly ending" costs one more call, and the assistant still remembers which names it already ruled out. That is the loop the shortage of good names actually demands: not one clever search, but forty ordinary ones you do not have to type.
How it compares with other domain MCP servers
| Server | How it decides availability | Coverage | Account |
|---|---|---|---|
| Domain Generator | Its own copy of the registry lists, rebuilt daily | 1,000+ extensions | Required |
| mcp-domain-availability | DNS, then WHOIS, then socket | 50+ extensions | None |
| Instant Domain Search | Its own search API, "as fast as 10ms" | Not stated | Not stated |
| GoDaddy | Public registrar data | Registrar catalogue | "No GoDaddy account or API credential is required" |
Pick a different one when your question is different. A single authoritative check on one name the minute before you buy belongs at a registrar, not against any cached list. WHOIS record details, expiry dates and nameservers are not something this server returns. Neither is buying: no MCP server here registers anything, and the GoDaddy server says the same of itself. Where this one earns its place is breadth and speed at the stage where you still have forty ideas and no decision, which is also when deciding how many names to defend is cheapest to think about.
Frequently asked questions
Do I need an account to use it?
Yes, for every tool. Search and generation are free and anonymous on the website, but the MCP server connects as a specific person: it reads your favourite extensions, writes to your shortlist and reads your history, none of which exists without an account. An unauthenticated client gets a 401 from the transport before any tool runs.
Does it cost anything?
No. There is no paid tier, and the rate limits apply to everyone equally.
Which clients work?
Anything that speaks MCP over streamable HTTP. Claude Code, Claude Desktop, Cursor, VS Code, Windsurf, Cline, Gemini CLI and Codex CLI have their exact file paths and field names written out on the connect page; the rest need the endpoint and nothing else.
Can it register a domain for me?
No. It reads availability and writes your own shortlist. Registration stays at a registrar, deliberately: an assistant that can spend money on a name it invented is a worse idea than it sounds.
How current is the availability data?
The registry list is rebuilt daily. Treat any result as accurate to within a day, and confirm at a registrar before you pay. For a name you are seconds from buying, that gap matters; for the first forty you are still weighing, it does not.
Does the assistant see my browsing?
It sees what the two history tools return: the names you recently searched and the keywords you generated from, on the website. It gets nothing else about the account, and nothing you do through the assistant is written back into that history.
What to do next
Connect a client at the MCP page, which has the snippet for yours and a key if you want one. If you would rather stay in a browser, domain search and the domain name generator run the same checks against the same list, and the shortlist you build in either place is the one the assistant reads.
Image credits
Backlit keyboard by Colin, CC BY-SA 4.0, via Wikimedia Commons.
