Skip to main content
Glama
stucchi

domain-check-mcp

by stucchi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

domain-check-mcp

PyPI License: MIT Python MCP Server MCP Enabled Claude Compatible GitHub stars GitHub issues

MCP server for checking domain name availability. Supports 500+ TLDs via RDAP, with WHOIS fallback for .de and .cn.

Installation

uvx domain-check-mcp

Related MCP server: domain-mcp

Usage in .mcp.json

{
  "mcpServers": {
    "domain-check": {
      "command": "uvx",
      "args": ["domain-check-mcp"]
    }
  }
}

Tools

  • check_domain — Check if a domain name is available for registration

Example

check_domain("example.com")

Returns:

{
  "domain": "example.com",
  "available": false,
  "status": "registered"
}

Supported TLDs

Via RDAP (500+)

All major gTLDs and many ccTLDs with RDAP support, sourced from the IANA RDAP Bootstrap:

.com, .net, .org, .info, .app, .dev, .io, .xyz, .site, .shop, .uk, .fr, .nl, .pl, .consulting, .cloud, .tech, .blog, .store, .online, and many more.

Via WHOIS

TLD

WHOIS Server

.de

whois.denic.de

.cn

whois.cnnic.cn

.fj

www.whois.fj

.gs

whois.nic.gs

.bayern

whois.nic.bayern

.cat

whois.nic.cat

.eus

whois.nic.eus

.radio

whois.nic.radio

.scot

whois.nic.scot

.sport

whois.nic.sport

How it works

  1. Extracts the TLD from the domain name

  2. Routes to the appropriate adapter (RDAP or WHOIS)

  3. RDAP: HTTP lookup — 404 means available, 200 means registered

  4. WHOIS: TCP port 43 lookup — pattern matching on the response

  5. Returns a structured result with availability status

Development

git clone https://github.com/stucchi/domain-check-mcp.git
cd domain-check-mcp
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
pytest

License

MIT

Available Tools

2 tools
check_domainC

Check if a domain name is available for registration.

Supports 500+ TLDs via RDAP (including .com, .net, .org, .app, .dev, .io, and many more) plus .de and .cn via WHOIS.

ParametersJSON Schema
NameRequiredDescriptionDefault
domainYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior. It mentions RDAP and WHOIS methods and TLD coverage, but fails to describe the response format (e.g., boolean, details), error handling, rate limits, or caching. This leaves the agent unsure of what to expect from the output.

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?

The description is concise with two sentences: one stating the core purpose, the second detailing supported TLDs. No redundant information, but could be slightly more structured (e.g., listing example TLDs or output hint).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter and no output schema, the description should cover return value and behavior. It defines input and scope but omits output details (e.g., returns true/false or availability object). This is a notable gap for an AI agent to correctly use the results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for the single parameter 'domain'. The description adds context that it is a domain name for availability check, but does not specify format requirements (e.g., include TLD, no protocol, case sensitivity, IDN support). For a simple string, the added value is moderate, but more explicit guidance would be beneficial.

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 description clearly states the tool checks domain availability for registration, specifying verb ('check') and resource ('domain name'). It mentions support for many TLDs, but does not explicitly differentiate from the sibling tool 'check_domains' (which likely checks multiple domains). The name and single parameter imply a single domain, but explicit comparison would improve clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus the sibling 'check_domains'. There are no prerequisites, limitations, or context for selecting this tool over alternatives. The description only lists supported TLDs without usage recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_domainsA

Check multiple domain names for availability in bulk.

Accepts a list of domains and returns the availability status of each one. Supports 500+ TLDs via RDAP and additional TLDs via WHOIS.

ParametersJSON Schema
NameRequiredDescriptionDefault
domainsYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It mentions support for 500+ TLDs via RDAP and additional via WHOIS, adding useful context. However, it does not disclose rate limits, authentication needs, or output format details.

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?

Three sentences with no wasted words. Purpose, input, and technical detail are front-loaded. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description vaguely mentions 'returns the availability status' but lacks specifics (e.g., response format, error handling, batch size limits). For a bulk tool, more details on constraints would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds meaning by stating the parameter 'domains' is a 'list of domains', but does not specify format requirements (e.g., full domain syntax, case sensitivity). The addition is minimal.

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?

The description clearly states the verb 'check' and resource 'domain names' with the qualifier 'multiple' and 'in bulk'. This distinguishes it from the sibling tool 'check_domain', which presumably handles single domains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when checking multiple domains via 'in bulk' and 'list of domains', but does not explicitly state when not to use it (e.g., for a single domain, use check_domain). Lacks direct alternative reference.

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 updatesv1.1.1
    • First observedcheck_domain
    • First observedcheck_domains
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are clearly distinct: one checks a single domain, the other checks multiple domains in bulk. There is no overlap in purpose.

Naming Consistency5/5

Both tools follow the verb_noun pattern (check_domain, check_domains) consistently, with the plural form appropriately indicating bulk operation.

Tool Count4/5

With 2 tools, the server is minimal but appropriately scoped for its purpose—checking domain availability. The count is slightly low but reasonable for a focused utility.

Completeness4/5

The server covers both single and bulk domain availability checks, which is the core functionality. No major gaps are apparent, though it does not offer additional details like whois data.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Lookup-Domain

    xiaobenyang-com
    A
    license
    A
    quality
    D
    maintenance
    A Model Context Protocol (MCP) server that provides comprehensive domain name research tools, including RDAP, WHOIS, and DNS query functionality.
    1
    2
    Apache 2.0

  • domain-mcp

    itsalfredakku
    F
    license
    Not graded
    quality
    Not graded
    maintenance
    An MCP server for domain availability checks, WHOIS lookups, and domain suggestions using RDAP and TCP port 43. It allows users to perform bulk checks and retrieve registration details across multiple TLDs without requiring an API key.
    121 npm
    -