Skip to main content
Glama
imprvhub

Domain Availability Checker MCP

MCP Domain Availability Checker

Smithery

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 | sh

Homebrew (macOS/Linux):

brew install uv

Install 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

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.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Linux: ~/.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 claude

Manual Installation

For development or local testing:

  1. Clone the repository:

git clone https://github.com/imprvhub/mcp-domain-availability
cd mcp-domain-availability
  1. Install dependencies:

uv sync
  1. Run locally:

uv run src/mcp_domain_availability/main.py

Deploying 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.

  1. Edit the script: Open deploy.sh and replace ... with your Google Cloud PROJECT_ID. You can also change the REGION if needed.

  2. Run the script: Make the script executable and run it.

    chmod +x deploy.sh
    ./deploy.sh
The 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.

  1. Set environment variables:

    export PROJECT_ID="<YOUR_PROJECT_ID>"
    export REGION="<YOUR_REGION>"
    export IMAGE="gcr.io/$PROJECT_ID/mcp-domain-availability:latest"
  1. Build and push the Docker image:

    docker buildx build --platform linux/amd64 -t $IMAGE --push .
  1. 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_ID

Note: 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.

  1. RDAP — the registry's own RDAP service, discovered through IANA's bootstrap registry (about 1,200 TLDs). This is authoritative.

  2. WHOIS — only for TLDs with no RDAP service (.io, .co, .me, .de, .es and 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.

  3. DNS — a name that resolves is definitely registered.

Each domain comes back as one of three statuses:

Status

Meaning

available

The registry confirmed there is no registration

taken

The registry confirmed a registration, or the name resolves in DNS

undetermined

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 --domain flag 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_domain

Check one specific domain

domain: e.g. mysite.com. A bare name with no TLD is checked across the popular TLDs

suggest_domains

Check one name across many TLDs

name: e.g. mysite; category: popular (default, 12), country (36), new (49) or all (~95)

Supported TLD Categories

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 TLDs

Specific 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, whois or dns)

Development

Run the offline test suite (no network required):

uv sync
uv run python -m unittest discover -s tests -v

Check a domain from the command line:

uv run mcp-domain-availability-cli example.com
uv run mcp-domain-availability-cli mysite popular

Troubleshooting

"Server disconnected" error

If you see connection errors in Claude Desktop:

  1. Verify uvx installation:

    • Run uvx --version to ensure uvx is properly installed

    • Reinstall uv if necessary: curl -LsSf https://astral.sh/uv/install.sh | sh

  2. 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:

  1. Refresh the cached install:

    • Run uvx --refresh --from git+https://github.com/imprvhub/mcp-domain-availability mcp-domain-availability

    • If you installed it as a persistent tool, run uv tool upgrade mcp-domain-availability

  2. 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:

  1. Network connectivity:

    • Verify internet connection is stable

    • Check if DNS servers are accessible

  2. 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:

  1. Verify configuration syntax:

    • Ensure JSON syntax is valid in claude_desktop_config.json

    • Check that all brackets and quotes are properly matched

  2. 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 logic

  • Domain checking functions with DNS, WHOIS, and socket fallback methods

  • TLD management with categorized lists

  • Async processing for parallel domain checks

Building

uv build

Testing

uv run pytest

Local Development

uv run main.py

Security 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.

Available Tools

2 tools
check_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.
ParametersJSON Schema
NameRequiredDescriptionDefault
domainYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.
ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
categoryNopopular

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

  1. 2 tool updatesv0.5.0
    • Changedcheck_domain3 fields changed
      • addedInput schema / properties / domain
        Added value: +{
        +  "title": "Domain",
        +  "type": "string"
        +}
      • removedInput schema / properties / domain_query
        Removed value: -{
        -  "title": "Domain Query",
        -  "type": "string"
        -}
      • changedInput schema / required
        Previous value: -[
        -  "domain_query"
        -]New value: +[
        +  "domain"
        +]
    • Addedsuggest_domains
  2. 1 tool updatev1.0.0
    • First observedcheck_domain

TDQS

A3.9/5.0

Scored across 2 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessSlow

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI assistants to check domain name availability using WHOIS lookups.
    12 npm
    4
    ISC
  • A
    license
    Not graded
    quality
    D
    maintenance
    Intelligent domain name suggestion service that checks real-time availability across multiple providers and works with MCP-compatible tools like Cursor and Claude Code.
    13
    Apache 2.0
  • A
    license
    Not graded
    quality
    A
    maintenance
    A 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
  • A
    license
    Not graded
    quality
    C
    maintenance
    A 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