Skip to main content
Glama
3viky

Domain Checker MCP Server

by 3viky
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Domain Checker MCP Server

Model Context Protocol (MCP) server for domain availability checking and intelligent domain recommendations.

Purpose

Provides AI agents with domain name checking capabilities, including:

  • Check if a single domain is available for registration

  • Batch check multiple domains at once

  • Generate intelligent domain name suggestions based on keywords

  • Support for multiple TLDs (Top Level Domains)

Related MCP server: MCP Domain Availability Server

Features

Available Tools

Tool

Description

check_domain

Check if a single domain name is available

check_domains_batch

Check availability for multiple domains at once

suggest_domains

Generate domain name suggestions based on keywords

Intelligent Features

  • WHOIS Integration: Uses the whoiser library for accurate domain availability checks

  • Multi-TLD Support: Check domains across .com, .org, .net, .io, .app, and more

  • Smart Suggestions: Generates creative domain combinations from keywords

  • Batch Processing: Efficiently check multiple domains in a single request

Installation

# Install dependencies
npm install
# or
pnpm install

# Build the server
npm run build

Configuration

No configuration required by default. The server uses public WHOIS services.

For Claude Code MCP Configuration

Add to your ~/.config/claude-code/mcp-servers.json:

{
  "mcpServers": {
    "domain-checker": {
      "command": "node",
      "args": ["/path/to/mcp-domain-checker/dist/index.js"]
    }
  }
}

Usage Examples

Check Single Domain

// Check if example.com is available
await check_domain({ domain: "example.com" })

Batch Check Multiple Domains

// Check multiple domains at once
await check_domains_batch({
  domains: ["myapp.com", "myapp.io", "myapp.dev"]
})

Generate Domain Suggestions

// Get 10 domain suggestions for a tech startup
await suggest_domains({
  keywords: ["tech", "startup", "ai"],
  count: 10,
  tlds: ["com", "io", "ai", "dev"]
})

Development

# Watch mode for development
npm run dev

# Build for production
npm run build

# Type checking
tsc --noEmit

API Reference

check_domain

Check if a single domain name is available.

Parameters:

  • domain (string, required): The domain name to check (e.g., "example.com")

Returns:

  • available (boolean): Whether the domain is available

  • domain (string): The checked domain name

  • whoisData (object, optional): Raw WHOIS data if available

check_domains_batch

Check availability for multiple domain names at once.

Parameters:

  • domains (string[], required): Array of domain names to check

Returns:

  • Array of availability results for each domain

suggest_domains

Generate domain name suggestions based on keywords.

Parameters:

  • keywords (string[], required): Keywords to use for suggestions

  • count (number, optional): Maximum number of suggestions (default: 10)

  • tlds (string[], optional): TLDs to check (default: ["com", "org", "net", "io", "app"])

Returns:

  • Array of available domain suggestions with metadata

License

MIT

Author

Built with Claude Code

Repository

https://github.com/3viky/mcp-domain-checker

Available Tools

3 tools
check_domainA

Check if a single domain name is available for registration

ParametersJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain name to check (e.g., "example.com")

TDQS

A4/5.0
Behavior4/5

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

Without annotations, the description carries full burden. It correctly states the tool checks availability, implying a read-only lookup. It does not detail side effects or response format, which is acceptable for a simple lookup, but could explicitly mention non-destructiveness.

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 (11 words) that front-loads the purpose. Every word is necessary; no extraneous information.

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?

For a simple tool with one parameter and no output schema, the description is adequate. It could mention output type (e.g., boolean) or suggest using check_domains_batch for multiple domains, but it is functionally complete.

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 baseline is 3. The tool description does not add extra meaning beyond what the schema already provides (e.g., format example). The parameter is sufficiently described in the schema.

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 tool's action (check), resource (domain name), and outcome (availability for registration). It distinguishes from siblings by specifying 'single', which contrasts with 'batch' in check_domains_batch and suggestion in suggest_domains.

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 description implies usage for checking a single domain, but does not explicitly state when to use this over siblings like check_domains_batch for multiple domains or suggest_domains for alternative names. No exclusions or prerequisites are mentioned.

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

check_domains_batchB

Check availability for multiple domain names at once

ParametersJSON Schema
NameRequiredDescriptionDefault
domainsYesArray of domain names to check (e.g., ["example.com", "example.org"])

TDQS

B3/5.0
Behavior2/5

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

No annotations provided, so description must bear full burden. It only says 'check availability' without disclosing read-only nature, rate limits, return format, or side effects. Inadequate for a batch operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise but omits critical details. Lacks front-loading of key behavioral info. Would benefit from more structure.

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?

No output schema and no annotations, yet description fails to explain return values, errors, or usage examples. Incompleteness leaves agent underinformed.

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% with a clear description of the 'domains' parameter. The tool description adds minimal new meaning beyond rephrasing the schema. Baseline 3 is appropriate.

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 action (check availability) and the resource (multiple domain names). It distinguishes from siblings 'check_domain' and 'suggest_domains' by noting the batch aspect.

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 explicit guidance on when to use this tool vs alternatives. Siblings are listed but not referenced in description. No mention of limits or prerequisites.

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

suggest_domainsB

Generate domain name suggestions based on keywords

ParametersJSON Schema
NameRequiredDescriptionDefault
tldsNoTLDs to check (default: ["com", "org", "net", "io", "app"])
countNoMaximum number of suggestions to return (default: 10)
keywordsYesKeywords to use for domain suggestions (e.g., ["tech", "startup"])

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries full responsibility. It only states 'generate suggestions based on keywords' without disclosing whether suggestions come with availability info, any restrictions, or side effects. This is insufficient for a tool with no annotation coverage.

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 a single, concise sentence that gets to the point. It is front-loaded with the core action. There is no wasted text, but it could benefit from slightly more detail without losing conciseness.

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?

The tool is simple but lacks output schema and annotations. The description does not explain what the suggestions look like (e.g., are they just name strings or also include TLD? Are they pre-checked for availability?). Given the minimal context, the description is incomplete.

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% - all three parameters have descriptions in the schema. The description adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.

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 'Generate domain name suggestions based on keywords', identifying the specific verb (generate) and resource (domain name suggestions). It distinguishes from siblings check_domain and check_domains_batch, which focus on checking availability, not generating suggestions.

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?

No explicit guidance on when to use this tool versus siblings. The sibling names imply this is for suggestions and the others for checking, but the description does not state when to prefer this or mention any exclusions.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedcheck_domain
    • First observedcheck_domains_batch
    • First observedsuggest_domains
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: checking a single domain, checking multiple domains in batch, and generating suggestions. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: check_domain, check_domains_batch, suggest_domains. The naming is predictable and clear.

Tool Count5/5

Three tools is an appropriate number for a domain checker server, covering the essential operations without unnecessary bloat.

Completeness5/5

The tool set covers the core domain checking workflow: single check, batch check, and suggestions. There are no obvious missing operations for a domain availability service.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Whois MCP

    modelcontextprotocol-servers
    A
    license
    B
    quality
    D
    maintenance
    Enables AI agents to perform WHOIS lookups to retrieve domain registration details, including ownership, registration dates, and availability status without requiring browser searches.
    4
    57
    21
    MIT

  • MCP Domain Availability Server

    yenyifu
    A
    license
    A
    quality
    D
    maintenance
    Enables AI assistants to check domain name availability for single or multiple domains using DNS, RDAP, and WHOIS lookups. It provides detailed registration status including registrar information and expiration dates while supporting bulk checks of up to 50 domains.
    2
    MIT

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

  • mcp-server-canyougrab

    einiba
    A
    license
    A
    quality
    C
    maintenance
    Confidence-scored domain availability checking for AI agents via real-time DNS and WHOIS lookups. Bulk check up to 100 domains, WHOIS enrichment, and quota monitoring. All tools are read-only.
    3
    1
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/3viky/mcp-domain-checker'

If you have feedback or need assistance with the MCP directory API, please join our Discord server