domain-checker-mcp
Provides a tool for checking domain name availability using the RapidAPI Domain Status API.
Click on "Install 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-mcpCheck whether mybrand.ai 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
A production-ready remote MCP (Model Context Protocol) server that lets AI assistants such as Claude check whether a domain name is available for registration — powered by the RapidAPI Domain Status API.
"Check whether mybrand.ai is available." → Claude calls the
check_domain_availabilitytool → clean, structured answer.
Transport: stateless Streamable HTTP (MCP spec
2026-07-28,mcp-handlerv2 / MCP SDK v2)Deploy target: Vercel serverless (also runs locally over stdio)
One tool:
check_domain_availability
Live instance
A hosted instance is running here:
MCP endpoint |
|
Landing page | |
Health |
Add that endpoint URL to Claude (step by step below) and start asking. It shares one free RapidAPI key across everyone, so it is rate-limited and may return "rate limiting" messages under load — for anything real, run your own copy (free, ~3 minutes).
Related MCP server: Domain Checker MCP Server
Table of contents
What it does
Tool |
|
Input |
|
Output | Readable text + |
Input is normalised before the upstream call: trimmed, lower-cased, a leading dot on the
TLD is removed (.AI → ai), a redundant TLD in the name is de-duplicated
(mybrand.ai + ai → mybrand), and full URLs / invalid characters are
rejected with a safe message.
Use it in Claude — step by step
Examples below use the live instance (
https://domain-checker-mcp.vercel.app/mcp). If you deployed your own, swap inhttps://<your-project>.vercel.app/mcp.
A. Claude.ai (web) or Claude Desktop — custom connector
Open Claude → click your name / avatar → Settings.
Go to Connectors (on some plans: Feature preview → Model Context Protocol).
Click Add custom connector (or Add connector → Custom).
Fill in:
Name:
Domain CheckerURL:
https://domain-checker-mcp.vercel.app/mcp← note the/mcppath
Click Add / Save. The connector needs no authentication.
Open a chat. Click the connectors / tools button (🔌 or the slider icon near the prompt box) and make sure Domain Checker is enabled for the conversation.
Ask a question (see prompts to try). The first time, Claude will ask permission to use the tool — click Allow.
Requirements: custom/remote MCP connectors are available on Claude Pro, Max, Team, and Enterprise. On a free plan you can still use it locally over stdio (see Local: Claude Desktop over stdio).
B. Claude Code (CLI)
claude mcp add --transport http domain-checker https://domain-checker-mcp.vercel.app/mcpVerify:
claude mcp list
# domain-checker http https://domain-checker-mcp.vercel.app/mcp ✓ connectedThen in a Claude Code session just ask: "Is mybrand.io available?"
To remove it later: claude mcp remove domain-checker.
C. Local: Claude Desktop over stdio
If you cloned the repo and want to run it locally (no hosting, works on any plan):
npm install
npm run buildEdit your claude_desktop_config.json
(macOS: ~/Library/Application Support/Claude/claude_desktop_config.json,
Windows: %APPDATA%\Claude\claude_desktop_config.json):
{
"mcpServers": {
"domain-checker": {
"command": "node",
"args": ["/absolute/path/to/domain-checker-mcp/dist/index.js"],
"env": { "RAPIDAPI_KEY": "your_rapidapi_key_here" }
}
}
}Restart Claude Desktop. The tool appears under the 🔌 menu.
D. Cursor / Windsurf / other MCP clients
Add to the client's MCP config (e.g. .cursor/mcp.json):
{
"mcpServers": {
"domain-checker": { "url": "https://domain-checker-mcp.vercel.app/mcp" }
}
}Prompts to try
Check mybrand.ai
Is mybrand.com available?
Check whether mybrand.io is available
Are any of these free: acme.dev, acme.io, acme.ai?Claude should call check_domain_availability with, e.g.,
{ "name": "mybrand", "tld": "ai" } and report the status.
Run your own copy (recommended)
The public repo is meant to be cloned and self-hosted — each person runs their own instance with their own free RapidAPI key. That way nobody shares a rate limit or a bill. Takes ~3 minutes.
1. Get a RapidAPI key
Sign up at rapidapi.com.
Open the Domain Status API and click Subscribe to Test (there is a free tier).
Copy your
X-RapidAPI-Key.
2. Get the code
git clone https://github.com/LearnerSumit/domain-checker-mcp.git
cd domain-checker-mcp
npm install(Or click Fork on GitHub first, then clone your fork.)
3. Deploy to Vercel
Option A — Dashboard (easiest)
Push your copy to GitHub (
git push).Go to https://vercel.com/new and import the repository.
Leave build settings as detected (the included
vercel.jsonhandles everything — no framework, no build command). Application Preset "Node" is fine.Expand Environment Variables. Vercel pre-detects
RAPIDAPI_KEYfrom.env.examplewith the placeholder value — replace it with your real key (leave it applied to all environments):Name
Value
RAPIDAPI_KEYyour RapidAPI key (not
your_rapidapi_key_here)Click Deploy.
If you add or change the key after the first deploy, go to Deployments → ⋯ → Redeploy so it takes effect.
Option B — Vercel CLI
npm i -g vercel
vercel login
vercel link
vercel env add RAPIDAPI_KEY production # paste key when prompted
vercel env add RAPIDAPI_KEY preview
vercel env add RAPIDAPI_KEY development
vercel --prod4. Verify
curl https://your-project.vercel.app/health
# {"status":"ok","server":"domain-checker-mcp","version":"1.0.0","configured":true}
curl -s -X POST https://your-project.vercel.app/mcp \
-H 'content-type: application/json' \
-H 'accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'Visiting https://your-project.vercel.app/ in a browser shows a small landing page with
the endpoint and connect instructions.
5. Connect it to Claude
Use the URL https://your-project.vercel.app/mcp and follow
Use it in Claude.
Local development
cp .env.example .env # then set RAPIDAPI_KEY in .env
npm run dev # HTTP dev server → http://localhost:3000/mcp (+ /health, + landing page)
npm run dev:stdio # stdio transport with hot reload
npm run typecheck # tsc --noEmit
npm test # Vitest (external API mocked — no key or network needed)
npm run build # compile src/ → dist/
npm start # run the compiled stdio server (dist/index.js)
npm run inspect # open the MCP InspectorTest the running dev server with the Inspector (Streamable HTTP, URL
http://localhost:3000/mcp) or curl:
curl -s -X POST http://localhost:3000/mcp \
-H 'content-type: application/json' -H 'accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"check_domain_availability","arguments":{"name":"mybrand","tld":"ai"}}}'Architecture & project layout
Claude ──HTTPS──▶ Vercel Function (api/mcp.ts)
│
▼
mcp-handler (Streamable HTTP, stateless)
│
▼
check_domain_availability tool (src/tools/domain.ts)
│ │
▼ ▼
per-client rate limit validation/domain.ts ──▶ services/rapidapi.ts
(src/utils/rateLimit) (normalise + validate) (the only outbound call:
timeout + error mapping)
│
▼
POST https://domainstatus.p.rapidapi.com/v1/domain/availablePath | Purpose |
| Vercel Function — the remote MCP endpoint ( |
| Vercel Function — |
| Landing page served at |
| Builds the |
| Local stdio entrypoint ( |
| Local HTTP dev server — same handler as Vercel |
| The |
| The only module that calls RapidAPI |
| Input normalisation & validation |
| RapidAPI response schema + clean result types |
| Env-var configuration |
| In-memory per-client rate limiter |
|
|
| Minimal structured logger (stderr, redacts secrets) |
| Loads |
| Vitest unit tests (external API mocked) |
The MCP tool
Name: check_domain_availability
Input schema — both fields required strings:
{ "name": "mybrand", "tld": "ai" }Input | Behaviour |
| → |
| → |
| ❌ rejected — "…not a URL" |
| ❌ rejected — "Invalid domain name." |
any TLD ( | ✅ generic validation, nothing hard-coded |
Result:
Domain: mybrand.ai
Status: AVAILABLE
TLD Valid: Yes
Check Method: WHOIS
Lookup Time: 918ms{
"domain": "mybrand.ai",
"name": "mybrand",
"tld": "ai",
"available": true,
"tldValid": true,
"checkMethod": "whois",
"elapsed": "918ms"
}Configuration
All via environment variables (.env locally, project settings on Vercel):
Variable | Required | Default | Notes |
| ✅ | – | Your RapidAPI key. Never commit it. |
|
| Upstream request timeout (clamped 1 000–60 000). | |
|
| Rarely changed. | |
|
| Tool calls per client per window. | |
|
| Rate-limit window length. | |
|
|
| |
|
| Local HTTP dev server only. |
Error handling
Every failure becomes a safe tool result with isError: true — never a stack trace,
never a secret, never a raw upstream body.
Situation | HTTP | Message |
| – |
|
Invalid input | – |
|
Auth failure | 401 / 403 |
|
Rate limited (upstream) | 429 |
|
Rate limited (this server) | – |
|
Upstream down | 5xx |
|
Timeout | – |
|
Malformed / unexpected body | – |
|
Security & abuse protection
✅ API key read only from
process.env.RAPIDAPI_KEY— never hard-coded✅
.envis git-ignored;.env.exampleholds only a placeholder✅ API key never returned to the client, never logged (logger redacts it and any
key/secret/token/authorizationfield), never in an error message✅ Input validated & normalised; full URLs and bad characters rejected
✅ No user-controlled URLs — only the single hard-coded RapidAPI endpoint is called (no SSRF surface)
✅ Request timeout via
AbortController(default 10 s, capped)✅ Per-client (per-IP) rate limiting on tool calls
✅ Stateless transport — no session data persisted
Notes for hosting a public shared instance
If you deploy one instance and share the URL publicly (e.g. on Reddit) so strangers connect their Claude to it:
One RapidAPI key serves everyone. All lookups count against your quota and your bill. The free Domain Status tier is very small (expect frequent
429s under load). Move to a paid RapidAPI plan, or ask people to self-host.Keep
RATE_LIMIT_MAXsane (default 15/min/IP). It is per-serverless-instance, so it caps a single abuser but is not a strict global limit. For hard limits put Vercel Firewall or a KV-backed limiter in front.Rotate the key if it ever leaks (screenshots, commits, logs): regenerate it in the RapidAPI dashboard and update only the Vercel env var.
There is no auth on the tool by design (so "anyone can use it"). If you want to restrict access,
mcp-handlershipswithMcpAuth— wrap the handler insrc/server.ts.The safest public model is share the repo, not the endpoint — point people at Run your own copy.
Tech stack
Node.js 20+ · TypeScript (strict) · @modelcontextprotocol/server v2 · mcp-handler v2
(Streamable HTTP) · zod v4 · native fetch · Vitest · Vercel.
Author
Sumit Kumar · GitHub · LinkedIn · sumitdbg255@gmail.com
If this saved you some time, a ⭐ on the repo is appreciated.
License
Available Tools
1 toolcheck_domain_availabilityCheck domain availabilityARead-onlyIdempotent
Check whether a domain name is available for registration. Provide the name and TLD separately (e.g. name "mybrand", tld "ai"). Returns availability, whether the TLD is valid, and which lookup method (usually WHOIS) was used.
| Name | Required | Description | Default |
|---|---|---|---|
| tld | Yes | The top-level domain, e.g. "ai", "com", "io". A leading dot (".ai") is accepted. | |
| name | Yes | The domain name without the TLD or a leading dot, e.g. "mybrand". Do not pass a full URL. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful behavioral detail beyond that by naming the return fields (availability, TLD validity, lookup method) and noting WHOIS is typical. No contradictions with annotations.
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?
Three concise sentences: the first states purpose, the second gives input guidance, the third describes the output. No filler or redundant content.
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 read-only tool with two fully documented parameters, the description covers invocation and return values, and annotations cover side-effect safety. Nothing essential is missing.
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 description coverage is 100%, and the schema already documents both `name` and `tld` with examples and constraints. The description's 'provide name and TLD separately' mostly reinforces the schema rather than adding new semantic meaning.
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 states a specific verb ('Check whether a domain name is available for registration') and a clear resource. It also explains the input pattern, making the tool's purpose unambiguous even without sibling tools to differentiate.
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?
The description makes the usage context clear: use it to check domain availability for registration. There are no sibling tools to contrast with, so explicit exclusions aren't necessary. It could be more explicit about when not to use it, but the intent is obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
There is only one tool, so an agent cannot confuse it with any other operation. The name and description clearly explain what it does and what inputs it expects.
The single tool uses a clear verb_noun convention: check_domain_availability. With only one tool, there are no naming clashes or inconsistent patterns to create confusion.
One tool is slightly under the typical 3-15 range, but for the server's narrow purpose of checking domain availability, it is a reasonable and focused surface. It could arguably include additional domain-related tools, but the count is not excessive or trivially mismatched.
For the stated purpose of checking whether a domain is available for registration, the tool covers the core operation fully: it validates the TLD, returns availability, and indicates the lookup method. There are no obvious dead ends within this narrow domain.
Maintenance
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
Check domain name availability via RDAP. Single, bulk, and smart suggestions. No API key needed.
Domain availability search, WHOIS lookup, TLD pricing and registry rules from name.ai. Read-only.
Confidence-scored domain availability checking for AI agents via CanYouGrab.it
Buy & manage domains from any AI chat: availability, register, DNS, email forwarding, AI bot stats.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to check domain availability across multiple TLDs with real-time pricing, brainstorm creative domain names, analyze domains for brandability and SEO potential, and search for domains by price and category without CAPTCHAs.203MIT
- AlicenseAqualityDmaintenanceEnables AI agents to check domain availability, perform batch domain lookups, and generate intelligent domain name suggestions across multiple TLDs using WHOIS integration.43MIT
- 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
- FlicenseNot gradedqualityCmaintenanceEnables AI assistants to perform real-time domain name availability checks and validate domain syntax according to RFC standards. It supports both stdio and SSE transports to bridge the gap between AI models and domain registration services.1
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/LearnerSumit/domain-checker-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server