Skip to main content
Glama
WeAreBraveLabs

domain-checker-mcp

by WeAreBraveLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Domain Checker MCP Server

Fast domain availability checker for Model Context Protocol (MCP). DNS + RDAP/WHOIS verification.

Built by Brave Labs

Features

  • Hybrid DNS + RDAP/WHOIS checking - Fast DNS lookup, then RDAP (with WHOIS fallback) for accuracy

  • Bulk checking - Check up to 100 domains in parallel

  • Parallel processing - Batched verification queries for optimal throughput

  • Name expansion - Check a base name across all popular TLDs automatically

  • Flexible filtering - Return only available, only taken, or all results

  • Error reporting - Clear error handling for timeouts and failures

Related MCP server: Domain Checker MCP Server

Installation

npm install -g @wearebravelabs/domain-checker-mcp

Configuration

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "domain-checker": {
      "command": "npx",
      "args": ["-y", "@wearebravelabs/domain-checker-mcp"]
    }
  }
}

Claude Code

Add to your MCP settings:

{
  "mcpServers": {
    "domain-checker": {
      "command": "npx",
      "args": ["-y", "@wearebravelabs/domain-checker-mcp"]
    }
  }
}

Tools

check_domains

Check specific domains for availability with full DNS + WHOIS verification.

// Check multiple domains
check_domains({
  domains: ["myapp.com", "myapp.io", "myapp.dev"]
})

// Filter to only available domains
check_domains({
  domains: ["example.com", "randomname123.com"],
  filter: "available"
})

Parameters:

  • domains (required): Array of domain names to check

  • filter (optional): "available" or "taken" - omit for all results

check_names

Check base names across popular TLDs automatically.

// Check "myproject" across all popular TLDs
check_names({
  names: ["myproject"]
})

// Check multiple names with specific TLDs
check_names({
  names: ["startup", "launchpad"],
  tlds: ["com", "io", "co", "app"],
  filter: "available"
})

Parameters:

  • names (required): Array of base names to check

  • tlds (optional): Specific TLDs to check (defaults to: com, net, org, io, co, app, dev, ai, xyz, me, info, biz, us, uk, ca, au)

  • filter (optional): "available" or "taken" - omit for all results

check_domains_quick

Fast DNS-only check without WHOIS verification. Use when speed matters more than accuracy.

check_domains_quick({
  domains: ["example.com", "test.io"]
})

Parameters:

  • domains (required): Array of domain names to check

  • filter (optional): "available" or "taken" - omit for all results

Note: DNS-only checks may show false positives for available domains. Use check_domains for verification.

Example Response

{
  "summary": {
    "total": 4,
    "available": 2,
    "taken": 2,
    "errors": 0,
    "totalTime": "634ms"
  },
  "available": [
    "myproject.io",
    "myproject.dev"
  ],
  "taken": [
    "myproject.com",
    "myproject.app"
  ]
}

With errors:

{
  "summary": {
    "total": 3,
    "available": 1,
    "taken": 1,
    "errors": 1,
    "totalTime": "10234ms"
  },
  "available": ["available-domain.com"],
  "taken": ["google.com"],
  "errors": [
    { "domain": "example.xyz", "error": "WHOIS timeout" }
  ]
}

How It Works

  1. DNS Check (Fast) - All domains are checked via DNS in parallel. If DNS resolves, the domain is definitely taken.

  2. RDAP/WHOIS Verification (Accurate) - Domains that pass DNS (no records found) are verified via RDAP (preferred) or WHOIS (fallback) to confirm availability. RDAP servers are loaded dynamically from the IANA bootstrap registry.

  3. Parallel Processing - Verification queries run in parallel batches of 20 for optimal throughput.

This hybrid approach gives you the speed of DNS checking with the accuracy of RDAP/WHOIS verification.

Development

# Install dependencies
npm install

# Build
npm run build

# Run locally
npm start

More from Brave Labs

bravelabs.com.au

License

MIT © Brave Labs

Available Tools

3 tools
check_domainsB

Check if domains are available for registration. Uses DNS + RDAP/WHOIS for accuracy.

ParametersJSON Schema
NameRequiredDescriptionDefault
filterNoFilter results: 'available' or 'taken'. Omit for all.
domainsYesDomain names to check (e.g., ['example.com', 'test.io'])

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. The mention of DNS + RDAP/WHOIS adds useful context about method and potential latency, but it omits details like read-only nature, rate limits, or error behavior. It is better than a bare description but still lacks comprehensive transparency.

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?

Two sentences, front-loaded with the primary purpose and followed by methodology. No redundancy, every word earns its place.

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?

The tool is simple but lacks an output schema. The description does not specify the return format (e.g., per-domain status) or behavior with invalid domains. For a check tool, this is a notable gap, though the filter parameter implies a list of 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?

Schema coverage is 100% for both parameters, so the structure already documents them. The description adds no additional parameter semantics, making the baseline score of 3 appropriate.

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, using a specific verb and resource. It also adds methodology (DNS + RDAP/WHOIS) which hints at accuracy, though it doesn't explicitly distinguish from sibling tools like check_domains_quick.

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?

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It merely states what it does, leaving the agent to infer appropriate contexts.

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

check_domains_quickA

Quick DNS-only check without RDAP/WHOIS verification. Fast but may have false positives for 'available'.

ParametersJSON Schema
NameRequiredDescriptionDefault
filterNoFilter results: 'available' or 'taken'. Omit for all.
domainsYesDomain names to check

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses that the check is DNS-only, skips RDAP/WHOIS, and may report false positives for 'available', providing meaningful behavioral insight beyond the schema. It does not cover rate limits or return format, but for a simple check tool, the key limitation is well communicated.

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?

The description is a single, front-loaded sentence of 17 words. It conveys the core purpose, the technical distinction, and the main limitation without any filler, earning its place entirely.

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?

Given the tool's simplicity (2 params, no output schema, no annotations), the description covers the essential trade-off and behavior. It could mention what the return looks like or explicitly reference the more accurate sibling, but for a quick check utility, it is sufficiently complete for an agent to select and invoke it correctly.

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 100%, so the baseline is 3. The description adds value by explaining the reliability of the 'available' filter in the context of the enum, warning about false positives, which gives deeper semantic meaning to that parameter choice.

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 it is a 'Quick DNS-only check' with a specific verb and resource, distinguishing it from the sibling 'check_domains' by noting the lack of RDAP/WHOIS verification. It also identifies the key trade-off of false positives for 'available', making the tool's scope unmistakable.

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 use when speed is prioritized over accuracy, noting it is 'fast but may have false positives for available'. This gives clear context for when to choose this tool over the more thorough alternative, though it does not explicitly name the alternative or state when not to use it.

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

check_namesC

Check base names across popular TLDs (e.g., ['myproject'] checks myproject.com, .io, .net, etc.)

ParametersJSON Schema
NameRequiredDescriptionDefault
tldsNoOptional: specific TLDs to check. Defaults to popular TLDs.
namesYesBase names to check (e.g., ['myproject', 'coolapp'])
filterNoFilter results: 'available' or 'taken'. Omit for all.

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 carries the full burden of behavioral disclosure. It only says 'check' without explaining the output format, whether it is read-only, or any limitations like rate limits or network dependencies.

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?

The description is a single concise sentence with a clear example. Every word earns its place and there is no redundancy.

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

Completeness2/5

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

Given no annotations and no output schema, the description is too brief to provide a complete understanding of the tool's behavior. It does not mention default TLDs, result filtering semantics, or return value structure, leaving significant gaps for an agent.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds a clarifying example for the 'names' parameter but does not provide additional meaning for 'tlds' or 'filter' beyond what the schema already defines.

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 states the verb 'check' and the resource 'base names' across popular TLDs, making the purpose clear. It does not explicitly distinguish from sibling tools like check_domains, but the example clarifies the expected input.

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?

The description provides an implied use case but gives no explicit guidance on when to use this tool versus check_domains or check_domains_quick. No exclusions or alternative recommendations are mentioned.

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. 3 tool updatesv1.0.2
    • First observedcheck_domains
    • First observedcheck_domains_quick
    • First observedcheck_names
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.7/5.0

Scored across 3 tools

Disambiguation4/5

check_domains and check_domains_quick are closely related but clearly differentiated by accuracy/speed, while check_names serves a distinct purpose by expanding a base name across TLDs. No two tools are truly ambiguous, though the overlap between the two domain checks is notable.

Naming Consistency5/5

All tool names follow a consistent 'check_' prefix with clear object descriptors. The variation 'check_domains_quick' is a natural modifier of the core check_domains operation, maintaining a predictable pattern.

Tool Count5/5

With only 3 tools, the set is tightly scoped for a domain checker. Each tool serves a distinct need (thorough, quick, and name-based checking), and the count feels appropriate rather than thin or bloated.

Completeness4/5

The tool set covers the core domain availability checking use case well, including both accurate and fast variants. A minor gap is the lack of a way to specify custom TLD lists for name-based checks, but this is a workaround and not a critical omission.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Domain Checker

    ahramadan44
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables checking domain name availability using WHOIS lookups and DNS resolution. Supports both single and batch domain checking with detailed availability analysis.
    -

  • Domain Checker MCP Server

    ajot
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables domain availability checking through dual verification using WHOIS lookups and DNS resolution. Supports both single and batch processing to provide detailed analysis on whether domains are likely available or already registered.
    4
    -

  • domain-mcp

    cfenzo
    F
    license
    A
    quality
    D
    maintenance
    Enables domain name availability checking through DNS and WHOIS lookups with confidence scoring. It supports searching across alternative TLDs and generating domain name variations for branding purposes.
    4
    -

  • DomainFinder MCP Server

    codingstark-dev
    A
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables users to check domain name availability across 877 TLDs, generate intelligent suggestions, and retrieve WHOIS registration information. It supports bulk domain checks and cross-TLD searches through natural language interfaces.
    0
    -