Domain Availability Checker MCP
Check domain availability and discover alternative TLDs through Claude/MCP.
Check a specific domain (e.g.,
mysite.com) for registration status.Check a bare name (e.g.,
mysite) across popular TLDs.Get
available,taken, orundeterminedresults with source (RDAP,WHOIS,DNS) and timing.Use bulk TLD suggestions across popular/country/new/all categories per README; the provided schema exposes only
check_domainwith requireddomain_query.Integrate with Claude Desktop via uvx or Smithery, and optionally deploy over SSE with Docker/Cloud Run.
Supports installation of the required uv package manager through Homebrew, enabling easier setup on macOS/Linux systems.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Domain Availability Checker MCPcheck if myawesomesite.com is available"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Domain Availability Checker
Features
Domain Availability Checking
Check availability across 50+ popular TLD extensions
Support for popular (.com, .io, .ai), country (.us, .uk, .de), and new TLDs (.app, .dev, .tech)
Authoritative verification over RDAP, the protocol that replaced WHOIS
WHOIS and DNS fallback for the few TLDs that publish no RDAP service
Smart TLD suggestions organized by popularity
Search Capabilities
Check specific domains with exact TLD matching
Bulk checking across supported extensions for a given name
Parallel processing for faster domain queries
Organized results by TLD categories
MCP Integration
Easy setup with uvx package management
Seamless integration with Claude Desktop
Real-time availability status updates
Performance metrics and timing information
AI Assistant Features
Natural language domain queries through Claude
Automated domain suggestion workflows
Smart recommendations based on availability
Demo
00:00 - Checking google.com availability
Testing a well-known premium domain to demonstrate the domain checking functionality and alternative TLD suggestions.
00:20 - Testing myawesomesite.com
Verifying availability for a custom domain name and exploring alternative extension options.
00:40 - Verifying techstartup2026.io
Exploring tech startup domain options and checking availability across multiple TLD extensions.
01:00 - Analyzing aitools domain
Checking competitive AI industry domains and analyzing market availability for startup naming.
Requirements
Python 3.10 or higher (3.12 recommended)
Claude Desktop
uv package manager
Dependencies Installation
Install uv package manager using one of these methods:
Official installer (recommended):
curl -LsSf https://astral.sh/uv/install.sh | shHomebrew (macOS/Linux):
brew install uvInstall Homebrew (if needed):
Visit https://brew.sh for installation instructions on all operating systems
Or run:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
The MCP server automatically manages Python dependencies through uvx.
Installation
Zero-Clone Installation (Recommended)
The MCP Domain Availability Checker supports direct installation without cloning repositories, using uvx for package management.
Configuration
The Claude Desktop configuration file is located at:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json
Edit this file to add the Domain Availability MCP configuration:
{
"mcpServers": {
"mcp-domain-availability": {
"command": "uvx",
"args": [
"--python=3.12",
"--from",
"git+https://github.com/imprvhub/mcp-domain-availability",
"mcp-domain-availability"
]
}
}
}If you already have other MCPs configured, simply add the "mcp-domain-availability" section inside the "mcpServers" object:
{
"mcpServers": {
"otherMcp": {
"command": "...",
"args": ["..."]
},
"mcp-domain-availability": {
"command": "uvx",
"args": [
"--python=3.12",
"--from",
"git+https://github.com/imprvhub/mcp-domain-availability",
"mcp-domain-availability"
]
}
}
}Installing via Smithery
To install mcp-domain-availability for Claude Desktop automatically via Smithery:
npx -y @smithery/cli@latest mcp add imprvhub/mcp-domain-availability --client claudeManual Installation
For development or local testing:
Clone the repository:
git clone https://github.com/imprvhub/mcp-domain-availability
cd mcp-domain-availabilityInstall dependencies:
uv syncRun locally:
uv run src/mcp_domain_availability/main.pyDeploying with Docker to Google Cloud Run
The MCP server supports two transport modes:
stdio (default): For Claude Desktop integration via stdin/stdout
sse: For HTTP/web deployments like Google Cloud Run
When deploying to Cloud Run, the MCP_TRANSPORT environment variable must be set to sse.
Prerequisites:
Google Cloud SDK installed and authenticated (
gcloud auth login)Docker installed and running
A Google Cloud Project with the Cloud Run and Container Registry APIs enabled
Using the Deployment Script
The easiest way to deploy is to use the deploy.sh script.
Edit the script: Open
deploy.shand replace...with your Google CloudPROJECT_ID. You can also change theREGIONif needed.Run the script: Make the script executable and run it.
chmod +x deploy.sh
./deploy.shThe script will build the Docker image, push it to Google Container Registry, and deploy it to Cloud Run with `MCP_TRANSPORT=sse`.Manual Deployment
Alternatively, you can run the commands manually.
Set environment variables:
export PROJECT_ID="<YOUR_PROJECT_ID>"
export REGION="<YOUR_REGION>"
export IMAGE="gcr.io/$PROJECT_ID/mcp-domain-availability:latest"Build and push the Docker image:
docker buildx build --platform linux/amd64 -t $IMAGE --push .Deploy to Google Cloud Run:
gcloud run deploy mcp-domain-availability \
--image $IMAGE \
--region $REGION \
--platform managed \
--allow-unauthenticated \
--port 8080 \
--set-env-vars MCP_TRANSPORT=sse \
--project $PROJECT_IDNote: For local Claude Desktop usage, no environment variables are needed. The server defaults to stdio transport mode.
How It Works
ICANN retired WHOIS as the required registration-data protocol in January 2025 in favour of
RDAP (RFC 7482/9082), so RDAP is the primary source here. It is unambiguous: a registry's
RDAP service answers 404 for an unregistered domain and 200 for a registered one.
RDAP — the registry's own RDAP service, discovered through IANA's bootstrap registry (about 1,200 TLDs). This is authoritative.
WHOIS — only for TLDs with no RDAP service (
.io,.co,.me,.de,.esand some other ccTLDs). The registry's WHOIS server is found via IANA referral and queried directly over port 43; only the first lines of the response are interpreted.DNS — a name that resolves is definitely registered.
Each domain comes back as one of three statuses:
Status | Meaning |
| The registry confirmed there is no registration |
| The registry confirmed a registration, or the name resolves in DNS |
| No authoritative source answered. Not the same as available |
undetermined exists because the previous version reported a domain as available whenever a
WHOIS lookup raised an error — including when the machine had no whois binary installed, in
which case every domain looked free. A result you cannot trust is now labelled as such.
Domains are checked concurrently, capped at 10 in flight to stay within registry rate limits.
Available Tools
Changed in 0.5.0: the
--domainflag is no longer required — ask for a domain in plain language. The flag is still accepted so existing prompts keep working. Bulk TLD checking moved into its own tool, so asking about one domain no longer triggers ~95 lookups.
Tool Name | Description | Parameters |
| Check one specific domain |
|
| Check one name across many TLDs |
|
Supported TLD Categories
Popular TLDs (12)
com, net, org, io, ai, app, dev, co, xyz, me, info, biz
Country TLDs (36)
us, uk, ca, au, de, fr, it, es, nl, jp, kr, cn, in, br, mx, ar, cl, pe, ru, pl, cz, ch, at, se, no, dk, fi, be, pt, gr, tr, za, eg, ma, ng, ke
New TLDs
tech, online, site, website, store, shop, cloud, digital, blog, news & more.
Example Usage
Here are examples of how to use the MCP Domain Availability Checker with Claude:
Single Domain Check
Is mysite.com available?Domain Name Research
Check "startup" across all TLDsSpecific Domain Verification
Is awesome.io taken?Output Format
The tool provides comprehensive results including:
Requested Domain: Status of the exact domain queried (if a specific TLD was provided)
Available Domains: Confirmed unregistered, sorted alphabetically
Unavailable Domains: Confirmed registered
Undetermined Domains: No authoritative answer, with the reason
Summary Statistics: Breakdown by TLD categories (Popular, Country, New TLDs)
Performance Metrics: Check duration and which source answered (
rdap,whoisordns)
Development
Run the offline test suite (no network required):
uv sync
uv run python -m unittest discover -s tests -vCheck a domain from the command line:
uv run mcp-domain-availability-cli example.com
uv run mcp-domain-availability-cli mysite popularTroubleshooting
"Server disconnected" error
If you see connection errors in Claude Desktop:
Verify uvx installation:
Run
uvx --versionto ensure uvx is properly installedReinstall uv if necessary:
curl -LsSf https://astral.sh/uv/install.sh | sh
Check Python version:
Ensure Python 3.10+ is available:
python3 --version
"ModuleNotFoundError: No module named 'mcp.server.fastmcp'"
Version 2.0 of the MCP Python SDK removed mcp.server.fastmcp. Releases of this server before
0.5.0 imported it without capping the SDK version, so any fresh install picked up SDK 2.x and
failed at startup. 0.5.0 is written for SDK 2.x. If you still see the error, uv is running a
cached copy of the old code:
Refresh the cached install:
Run
uvx --refresh --from git+https://github.com/imprvhub/mcp-domain-availability mcp-domain-availabilityIf you installed it as a persistent tool, run
uv tool upgrade mcp-domain-availability
Remove the old workaround: if you added
"--with", "mcp<2.0.0"to your client config, delete it. 0.5.0 requires SDK 2.x and will not start with that pin.
DNS resolution issues
If domain checks are failing:
Network connectivity:
Verify internet connection is stable
Check if DNS servers are accessible
Rate limiting:
Large bulk checks may hit rate limits from DNS/WHOIS services
The tool uses a semaphore to limit concurrent requests to 20
Configuration issues
If the MCP server isn't starting:
Verify configuration syntax:
Ensure JSON syntax is valid in
claude_desktop_config.jsonCheck that all brackets and quotes are properly matched
Restart Claude Desktop:
Close and restart Claude Desktop after configuration changes
Related MCP server: Domain Finder MCP Server
Development
Project Structure
main.py: Main entry point with MCP server and domain checking logicDomain checking functions with DNS, WHOIS, and socket fallback methods
TLD management with categorized lists
Async processing for parallel domain checks
Building
uv buildTesting
uv run pytestLocal Development
uv run main.pySecurity Considerations
The MCP Domain Availability Checker makes external network requests to DNS servers and WHOIS services. Users should be aware that:
Domain queries may be logged by DNS providers
WHOIS queries are typically logged and may be rate-limited
No personal information is transmitted beyond the domain names being checked
All queries are read-only and do not modify any external systems
Contributing
Contributions are welcome! Areas for improvement include:
Adding support for additional TLD categories
Implementing caching mechanisms for faster repeated queries
Enhancing WHOIS parsing for more detailed domain information
Improving error handling and retry mechanisms
License
This project is licensed under the Mozilla Public License 2.0 - see the LICENSE file for details.
Related Links
Available Tools
2 toolscheck_domainA
Check whether a specific domain name is registered.
Give a full domain such as "example.com". Availability comes from the registry's
RDAP service where one exists, which is authoritative; for TLDs without RDAP the
registry's WHOIS server and DNS are used, and the result may come back
"undetermined" rather than guessing.
Args:
domain: The domain to check, e.g. "mysite.com". A bare name with no
top-level domain is checked across the popular TLDs instead.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does real work: it discloses the resolution chain (RDAP where available and authoritative, otherwise registry WHOIS plus DNS) and warns that results may return 'undetermined' rather than guessing. That is exactly the kind of uncertainty disclosure an agent needs. It omits rate limits, latency, and error behavior, keeping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose in sentence one, followed by mechanism and then the Args block. Every section earns its place, though 'example.com' is used as an example twice (in the body and again in the args), a small redundancy. Size is appropriate for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure need not be described, and the description still helpfully flags the 'undetermined' outcome. With one parameter and a clear mechanism, the definition is complete enough to call correctly; only operational details like rate limits or error semantics are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% – the schema gives only a string type and required flag – so the description must compensate, and it does. It explains both accepted forms of the single parameter (full domain such as 'mysite.com' versus a bare name that is checked across popular TLDs), which materially changes what the call means and its cost.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line states a specific verb and resource: 'Check whether a specific domain name is registered.' An agent immediately knows this is a registration-availability lookup, not a suggestion generator. It does not explicitly name the sibling suggest_domains, but the functional gap between them is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is limited to input format: pass a full domain like 'example.com', or pass a bare name to sweep popular TLDs. There is no when-to-use-vs-suggest_domains statement, no note on when the check is appropriate, and no exclusions. The input-form guidance is useful but only implicitly signals usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_domainsA
Check one name across many top-level domains and report which are free.
Args:
name: The second-level name to check, without a dot, e.g. "mysite".
category: Which TLD set to check - "popular" (12 TLDs, the default),
"country" (36), "new" (49) or "all" (roughly 95). Larger sets take
proportionally longer.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| category | No | popular |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully discloses a performance trait (larger category sets take proportionally longer), which is genuine behavioral context, but says nothing about rate limits, auth, or side effects. Return contents are covered by the output schema, so that omission is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded summary sentence followed by a compact Args block. Every sentence adds information; there is no filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and both input parameters are fully documented. The only gap is the missing explicit when-to-use guidance relative to the sibling check_domain, which keeps this from being complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does: 'name' is specified as the second-level label without a dot with a concrete example, and 'category' enumerates all four accepted values with TLD counts and the default. This effectively supplies the enum the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check) and resource (one name across many TLDs) plus the result (which are free). The phrasing 'one name across many top-level domains' implicitly contrasts with the sibling check_domain, which appears to handle a single domain check, so the agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The multi-TLD scope implies when this tool applies versus check_domain, and the note that larger sets take longer gives a practical selection cue. However, it never names check_domain or states explicitly when to use one over the other, so the routing guidance is inferred rather than declared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.5.0- Changed
check_domain3 fields changed- added
Input schema / properties / domainAdded value: +{ + "title": "Domain", + "type": "string" +} - removed
Input schema / properties / domain_queryRemoved value: -{ - "title": "Domain Query", - "type": "string" -} - changed
Input schema / requiredPrevious value: -[ - "domain_query" -]New value: +[ + "domain" +]
- Added
suggest_domains
1 tool update
v1.0.0- First observed
check_domain
TDQS
Scored across 2 tools
check_domain checks a single fully-qualified domain while suggest_domains sweeps one second-level name across many TLDs, so their core purposes differ. However, check_domain's fallback of checking a bare name across the popular TLDs partially duplicates suggest_domains' default 'popular' category, which could cause occasional misselection.
Both tools follow a clean verb_noun pattern (check_domain, suggest_domains) with snake_case throughout. The parameter names (domain, name, category) are also consistent and descriptive.
Two tools is thin even for a narrow availability-checking server; there is no single-vs-batch parity beyond TLD sweeps. It is defensible but borderline sparse.
The check-and-sweep pair covers the core lifecycle of domain availability lookup, including authoritative RDAP/WHOIS/DNS sources and TLD batching. Minor gaps remain: no way to check multiple distinct second-level names in one call and no results for pricing or registrar handoff.
Maintenance
Related MCP Connectors
- sentinelOAuthio.rootstuff
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
Domains MCP — domain registration lookup + availability search over live
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Onymu is an MCP server for domain name search, domain availability checking, and social media username lookup. Check a domain name against hundreds of TLDs in one call, including .com, .io, .ai, .co, and country-code extensions. Generate brandable startup names, business names, and product names from a keyword, and instantly see which ones are still available to register. Check username availability across major social networks so a brand name comes with matching handles. Save domains, set favorite TLDs, and recall recent searches to keep name research organized across sessions.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables AI assistants to check domain name availability using WHOIS lookups.12 npm4ISC
- AlicenseNot gradedqualityDmaintenanceIntelligent domain name suggestion service that checks real-time availability across multiple providers and works with MCP-compatible tools like Cursor and Claude Code.13Apache 2.0
- AlicenseNot gradedqualityAmaintenanceA Model Context Protocol (MCP) server that exposes the full WhoisFreaks API suite as AI-callable tools. Works with Claude Desktop, Cursor, Windsurf, VS Code, Continue, Zed, and any other MCP-compatible AI client.MIT
- AlicenseNot gradedqualityCmaintenanceA Model Context Protocol server for Internet.bs domain registrar API. Enables checking availability, registering, renewing, and managing domains and DNS from Claude or any MCP client.MIT