Skip to main content
Glama
kanishka3000

Domain Checker MCP Server

by kanishka3000

Domain Checker MCP Server

A Model Context Protocol (MCP) server that checks domain name availability using the WhoisJSON API.

Features

  • Check if domain names are available for registration

  • Get detailed registration information for registered domains

  • Easy-to-use HTTP API for testing

  • Built with TypeScript for type safety and readability

Related MCP server: MCP Domain Availability Server

API Limits

  • Rate Limit: 20 requests per minute

  • Monthly Limit: 1000 requests per month

Setup

Initial Setup

  1. Install dependencies:

npm install
  1. Create a .env file with your WhoisJSON API key:

WHOISJSON_API_KEY=your-api-key-here
PORT=6005
  1. Build the project:

npm run build

Usage

Option 1: Testing with HTTP Server

The HTTP mode is for testing only - it runs a REST API on port 6005 so you can verify everything works.

Start the HTTP server:

npm run start:http

Test it:

# Health check
curl http://localhost:6005/health

# Check a domain
curl http://localhost:6005/check/example.com

Stop the server when done testing (Ctrl+C).

Option 2: Using with Claude Desktop (MCP Mode)

This is the main use case - Claude Desktop will automatically start and manage the server.

Important: MCP mode uses stdio (not HTTP/ports), so there are no port conflicts. Claude starts the server automatically when it launches.

Steps to Configure:

  1. Build the project (if not already done):

npm run build
  1. Add to Claude Desktop config:

    • Mac: ~/Library/Application Support/Claude/claude_desktop_config.json

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

{
  "mcpServers": {
    "domain-checker": {
      "command": "node",
      "args": [
        "/FULL/PATH/TO/domain-checker-mcp/dist/index.js"
      ],
      "env": {
        "WHOISJSON_API_KEY": "your-api-key-here"
      }
    }
  }
}
  1. Replace the paths:

    • Change /FULL/PATH/TO/domain-checker-mcp to your actual project path

    • Change your-api-key-here to your WhoisJSON API key

  2. Restart Claude Desktop

  3. Test it: Ask Claude "Is example.com available?"

Moving to a Different Machine

To use this MCP server on another machine:

  1. Copy the project to the new machine

  2. Install dependencies: npm install

  3. Build: npm run build

  4. Update Claude Desktop config on the new machine with the correct path and API key

  5. Restart Claude Desktop

How It Works: HTTP vs MCP Mode

  • HTTP Mode (npm run start:http): Uses port 6005, for testing with curl/browser

  • MCP Mode (npm start or run by Claude): Uses stdio (no ports), for AI integration

These are completely separate - MCP mode does NOT use HTTP or ports, so they never conflict. Claude Desktop automatically starts the server in MCP mode when it launches.

MCP Tool: check_domain

Input:

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

Output:

If domain is available:

{
  "available": true,
  "registered": false,
  "domain": "myawesomesite123.com"
}

If domain is registered:

{
  "available": false,
  "registered": true,
  "domain": "EXAMPLE.COM",
  "created": "1995-08-14 04:00:00",
  "expires": "2026-08-13 04:00:00",
  "registrar": "RESERVED-Internet Assigned Numbers Authority",
  "nameservers": ["elliott.ns.cloudflare.com", "hera.ns.cloudflare.com"],
  "daysUntilExpiry": 125
}

Code Structure

  • src/index.ts - Main server code with clear, documented functions

  • .env - Environment configuration (API key, port)

  • tsconfig.json - TypeScript configuration

Development

Watch mode (auto-restart on changes):

npm run dev

Build:

npm run build

How It Works

  1. checkDomainAvailability() - Queries the WhoisJSON API with the domain name

  2. createMCPServer() - Sets up the MCP server with the check_domain tool

  3. createExpressServer() - Creates an HTTP server for easy testing

  4. main() - Entry point that starts either HTTP or MCP mode based on arguments

The code is written to be easy to read and understand, with clear function names, comments, and TypeScript types.

Available Tools

1 tool
check_domainB

Check if a domain name is available for registration. Returns availability status and registration details if the domain is taken.

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

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It mentions return value but omits behavioral traits like rate limits, authorization requirements, or cost implications.

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 sentence front-loads the action and immediately explains output. No wasted words.

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?

For a simple check with one parameter and no output schema, the description covers availability and registration details. However, it does not specify the format of the availability status or whether additional queries are needed for taken domains.

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 the single parameter. The description adds an example but no additional semantics beyond schema. Baseline of 3 applies.

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 name availability and returns registration details if taken. It is specific but could more precisely define 'registration details'.

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 on when to use this tool vs alternatives. There are no sibling tools, but no context about prerequisites or appropriate scenarios is provided.

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. 1 tool updatev1.0.0
    • First observedcheck_domain

TDQS

B3.4/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between tools. Its purpose is clearly defined and distinct.

Naming Consistency5/5

With a single tool, there is no inconsistency in naming. The name 'check_domain' is descriptive and follows a clear verb_noun pattern.

Tool Count3/5

The server has only one tool, which is borderline for a domain checker. While it serves the core function, additional tools for batch checks or WHOIS could be expected.

Completeness3/5

The tool covers checking domain availability, but lacks supplementary operations like bulk checks or WHOIS details, which are common in domain checking services.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • 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.
    -
  • 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
  • A
    license
    Not graded
    quality
    F
    maintenance
    Check domain name availability via RDAP. Single lookups, bulk checks (up to 50), and smart name suggestions with registration links. No API key needed.
    MIT