Domain Checker MCP Server
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Domain Checker MCP Servercheck if mynewproject.com is available"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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
Install dependencies:
npm installCreate a
.envfile with your WhoisJSON API key:
WHOISJSON_API_KEY=your-api-key-here
PORT=6005Build the project:
npm run buildUsage
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:httpTest it:
# Health check
curl http://localhost:6005/health
# Check a domain
curl http://localhost:6005/check/example.comStop 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:
Build the project (if not already done):
npm run buildAdd to Claude Desktop config:
Mac:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%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"
}
}
}
}Replace the paths:
Change
/FULL/PATH/TO/domain-checker-mcpto your actual project pathChange
your-api-key-hereto your WhoisJSON API key
Restart Claude Desktop
Test it: Ask Claude "Is example.com available?"
Moving to a Different Machine
To use this MCP server on another machine:
Copy the project to the new machine
Install dependencies:
npm installBuild:
npm run buildUpdate Claude Desktop config on the new machine with the correct path and API key
Restart Claude Desktop
How It Works: HTTP vs MCP Mode
HTTP Mode (
npm run start:http): Uses port 6005, for testing with curl/browserMCP Mode (
npm startor 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 devBuild:
npm run buildHow It Works
checkDomainAvailability() - Queries the WhoisJSON API with the domain name
createMCPServer() - Sets up the MCP server with the
check_domaintoolcreateExpressServer() - Creates an HTTP server for easy testing
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 toolcheck_domainB
Check if a domain name is available for registration. Returns availability status and registration details if the domain is taken.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain name to check (e.g., "example.com", "mysite.org") |
TDQS
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.
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.
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.
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.
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.
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 tool update
v1.0.0- First observed
check_domain
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion between tools. Its purpose is clearly defined and distinct.
With a single tool, there is no inconsistency in naming. The name 'check_domain' is descriptive and follows a clear verb_noun pattern.
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.
The tool covers checking domain availability, but lacks supplementary operations like bulk checks or WHOIS details, which are common in domain checking services.
Maintenance
Related MCP Connectors
Check domain name availability via RDAP. Single, bulk, and smart suggestions. No API key needed.
Normalized JSON for any domain across 1,200+ TLDs, reading WHOIS where no RDAP server exists.
Free, keyless domain registration lookup via RDAP: registered, available, registrar, expiration.
WHOIS/RDAP lookup, IP geolocation and Punycode conversion. 1400+ TLDs incl. IDN. No API key.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables checking domain name availability using WHOIS lookups and DNS resolution. Supports both single and batch domain checking with detailed availability analysis.-
- AlicenseAqualityDmaintenanceEnables 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.2MIT
- AlicenseNot gradedqualityFmaintenanceCheck domain name availability via RDAP. Single lookups, bulk checks (up to 50), and smart name suggestions with registration links. No API key needed.MIT
- FlicenseNot gradedqualityDmaintenanceEnables checking domain availability using WHOIS and DNS resolution, with support for single and batch queries.28-