MCP Domain Availability Server
Integrates with the GoDaddy OTE (Operational Test Environment) API to check domain availability and pricing. Provides tools for checking individual domains or bulk domain availability across multiple TLD suffixes, with support for fast and full check modes.
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., "@MCP Domain Availability Servercheck if myawesomesite.com and myawesomesite.org are 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.
MCP Domain Availability Server
A Model Context Protocol (MCP) server for checking domain availability and pricing using the GoDaddy OTE (Operational Test Environment) API.
Features
Check domain availability and pricing via GoDaddy OTE sandbox
Support for multiple TLD suffixes
Fast and Full check modes
Support for bulk domain checking
Rate limiting (60 calls per minute)
Normalized pricing in dollars with 2 decimal places
Consistent field naming and data structures
Period normalization (stored in months, displayed in years)
Related MCP server: Porkbun Domain Availability MCP Server
Installation
Using uv (Recommended)
# Install dependencies
uv add "mcp[cli]"
# Run with MCP Inspector for testing
DOMAIN_API_KEY="your-key:your-secret" mcp dev domain_availability/server.pyManual Installation
pip install -e .Configuration
Environment Variables
DOMAIN_API_KEY: Your GoDaddy OTE API credentials in format"key:secret"(required)
Note: The server uses GoDaddy OTE (sandbox) API by default: https://api.ote-godaddy.com
GoDaddy OTE Setup
Sign up for GoDaddy Developer account
Get OTE (sandbox) API credentials
Set the environment variable:
DOMAIN_API_KEY="your-ote-key:your-ote-secret"
MCP Configuration
Add this to your MCP client configuration (e.g., Claude Desktop's claude_desktop_config.json):
{
"mcpServers": {
"domain-availability": {
"command": "uv",
"args": ["run", "mcp-domain-availability"],
"env": {
"DOMAIN_API_KEY": "your-ote-key:your-ote-secret"
}
}
}
}Usage
Development & Testing
# Start MCP Inspector for testing
DOMAIN_API_KEY="your-key:your-secret" mcp dev domain_availability/server.pyThis will start the MCP Inspector at http://localhost:6274 for interactive testing.
Tools Available
The server provides one tool: check_domain_availability
Parameters
Option 1: Direct domain list
domains: Array of domain names to check (e.g.,["example.com", "example.org"])
Option 2: Base name with TLD suffixes
base_name: Base domain name (e.g.,"example")tld_suffixes: Array of TLD suffixes (e.g.,[".com", ".org", ".net", ".io"])
Optional
checkType:"FAST"or"FULL"(default:"FAST")FAST: Optimized for speedFULL: Optimized for accuracy
Examples
Check specific domains
{
"domains": ["example.com", "example.org", "example.net"],
"checkType": "FAST"
}Check base name with multiple TLDs
{
"base_name": "myawesomesite",
"tld_suffixes": [".com", ".org", ".net", ".io", ".dev", ".app"],
"checkType": "FULL"
}Response Format
Text Response:
Domain Availability Check Results:
✅ AVAILABLE DOMAINS:
• example.com - $12.99 USD for 1 year (Definitive)
• example.org - $8.99 USD for 2 years (Preliminary)
❌ UNAVAILABLE DOMAINS:
• example.net - Not available - Domain already registeredJSON Response (normalized fields):
{
"domains": [
{
"domain_name": "example.com",
"is_available": true,
"price_dollars": 12.99,
"currency_code": "USD",
"is_definitive": true,
"registration_period_months": 12
},
{
"domain_name": "example.net",
"is_available": false,
"price_dollars": 0.00,
"currency_code": "USD",
"is_definitive": true,
"registration_period_months": 12,
"error_message": "Domain already registered"
}
],
"errors": []
}Data Normalization
Price Normalization
Input: GoDaddy API returns prices in micro-units (1/1,000,000 of currency)
Output: Converted to dollars with 2 decimal places
Example:
12000000micro-units →$12.00 USD
Period Normalization
Storage: Period stored in months for consistency
Display: Converted to years for user-friendly display
Example:
12 months→"1 year",24 months→"2 years"
Field Naming
Consistent, explicit field names:
domain_name(instead ofdomain)is_available(instead ofavailable)price_dollars(instead ofprice)currency_code(instead ofcurrency)is_definitive(instead ofdefinitive)registration_period_months(instead ofperiod)error_message(instead oferror)
API Integration
This server integrates with GoDaddy OTE API:
Base URL:
https://api.ote-godaddy.comEndpoint:
GET /v1/domains/available?domain={domain}Headers:
Authorization: sso-key {key}:{secret}Rate Limit: 60 requests per minute
Authentication Format
Authorization: sso-key your-key:your-secretError Handling
The server handles various error conditions:
Missing API key
Invalid domains
API rate limits (429) - with retry guidance
Partial responses (203)
Authentication errors (401, 403)
Server errors (500)
Network timeouts
Development
Setup Development Environment
# Clone and setup
git clone <repository>
cd mcp-free-domain
uv add "mcp[cli]"
# Run tests
pytest
# Start development server
DOMAIN_API_KEY="test-key:test-secret" mcp dev domain_availability/server.pyTesting with MCP Inspector
Set your OTE credentials:
DOMAIN_API_KEY="your-key:your-secret"Run:
mcp dev domain_availability/server.pyOpen browser at
http://localhost:6274Use the session token displayed in terminal if prompted
Test the
check_domain_availabilitytool
License
MIT License
Support
For issues and questions, please create an issue in the repository.
Available Tools
1 toolcheck_domain_availabilityA
Check domain availability and pricing for multiple domains with different TLD suffixes. Rate limited: 60 calls per minute.
Args: domains: List of domain names to check (e.g., ['example.com', 'example.org']) checkType: Optimize for time (FAST) or accuracy (FULL) base_name: Base domain name to check with multiple TLD suffixes (e.g., 'example') tld_suffixes: List of TLD suffixes to check (e.g., ['.com', '.org', '.net'])
Returns: Formatted string with domain availability results
| Name | Required | Description | Default |
|---|---|---|---|
| domains | No | ||
| base_name | No | ||
| checkType | No | FAST | |
| tld_suffixes | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and includes useful behavioral information: the rate limit (60 calls per minute), the optimization trade-off between time (FAST) and accuracy (FULL), and that it returns a formatted string. The only missing piece is an explicit statement that the tool is non-destructive (read-only).
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?
The description is well-organized with a clear intro line, rate limit mention, structured Args block, and Returns line. Every sentence provides value, and there is no fluff or repetition.
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?
Given the tool has 4 optional parameters, no annotations, and an output schema, the description adequately explains both usage patterns (specific domains or base+TLDs) and the return format. However, it does not clarify whether the two methods (domains vs base_name/tld_suffixes) are mutually exclusive or what happens if both are provided, which could confuse an agent.
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?
The input schema has 0% description coverage; the description compensates by explaining the purpose of each parameter in the Args block: domains as a list of full names, checkType for optimization, and the base_name + tld_suffixes combination for generating names. However, it could be more specific (e.g., what FAST vs FULL entail in practice).
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 it checks domain availability and pricing for multiple domains with different TLD suffixes. This is a specific verb+resource combination. With no sibling tools, there is no need for differentiation, so a high score is appropriate.
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 implies its use for checking domain availability, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. There is no exclusion criteria or alternative tool mentioned, which is acceptable given no siblings but still limits direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Only one tool exists, so there is no ambiguity whatsoever. The agent cannot confuse it with any other tool.
With a single tool, naming consistency is not applicable, but the name 'check_domain_availability' is descriptive and follows a clear verb_noun pattern.
The server has only one tool for checking domain availability. This is minimal for its stated purpose; users might expect additional tools like WHOIS lookup or domain suggestions, making the count feel thin.
The single tool covers domain availability and pricing checks across multiple domains and TLDs, which is the core functionality. Minor gaps like WHOIS or registration are missing but not essential for the stated purpose.
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.
Search domain availability and pricing, straight from chat, then open a link to register.
Search, Register , Renew , Transfer and Manage domains
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 checking domain name availability and pricing through the Porkbun API, supporting both single and bulk domain queries with detailed pricing information including renewals, transfers, and premium status.21MIT
- FlicenseNot gradedqualityDmaintenanceEnables checking domain availability using WHOIS and DNS resolution, with support for single and batch queries.28
- AlicenseAqualityDmaintenanceEnables checking domain name availability for single or multiple domains using WHOIS and DNS verification.121MIT
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/OriShmila/mcp-domain-availability'
If you have feedback or need assistance with the MCP directory API, please join our Discord server