InstaDomain is an MCP server that lets AI agents check domain availability, purchase domains, and manage them — all from within your terminal.
Check a single domain: Look up availability and pricing for one domain name.
Bulk domain check: Check up to 50 domains at once using fast RDAP lookups.
Suggest domains: Generate AI-powered domain name ideas from a keyword and check their availability.
Buy via Stripe Checkout: Purchase using a credit/debit card; WHOIS privacy enabled by default.
Buy via Stripe MPP: Autonomous fiat payments using Shared Payment Tokens — no human interaction needed.
Buy with crypto: Purchase autonomously using USDC on Base via the x402 protocol — no browser or signup required.
Track order status: Poll a domain purchase order until it completes or fails.
Get EPP transfer code: Retrieve the authorization code to transfer your domain to another registrar.
Unlock domain: Remove the registrar transfer lock to allow outbound transfers.
Renew a domain: Renew for one additional year via Stripe Checkout.
Automatic DNS setup: A Cloudflare DNS zone is created automatically upon purchase, with a scoped API token returned to you.
Human-in-the-loop: Always shows price and asks for confirmation before buying.
Works with AI assistants: Integrates with Claude Code, Cursor, and Windsurf via the MCP protocol.
Automatically configures DNS zones and generates scoped API tokens for newly registered domains.
Enables domain registration and renewal payments through Stripe checkout.
Domain registration for AI agents. Check availability, buy domains, and configure DNS without leaving your terminal.
InstaDomain is an MCP server that lets AI coding assistants (Claude Code, Cursor, Windsurf) register domains on your behalf. Pay with Stripe Checkout, Stripe MPP (Machine Payments Protocol via Shared Payment Tokens), or x402 (USDC on Base). Domains are registered in your name with Cloudflare DNS auto-configured.
You're building a project in Claude Code. You need a domain. Today you alt-tab to Namecheap, search, add to cart, fill out forms, configure DNS. That's 10 minutes of context-switching.
With InstaDomain, your AI agent checks availability, shows you the price, and buys it in one conversation. DNS is ready before you finish your next prompt.
Related MCP server: Bloomfilter
Check domains - single domain with pricing, bulk check up to 50, or AI-generated suggestions
Buy domains - Stripe checkout (card), Stripe MPP (autonomous fiat via Shared Payment Tokens), or x402 (USDC on Base, no signup required)
Automatic DNS - Cloudflare zone created with scoped API token returned to you
Your domain, your name - registered as your property, not ours
Transfer out anytime - EPP auth codes and domain unlock built in
Auto-renew - enabled by default, renew via Stripe
WHOIS privacy - enabled by default
Tool | What it does |
| Check availability + price for a single domain |
| Check up to 50 domains at once |
| Generate and check domain name ideas for a keyword |
| Purchase via Stripe checkout |
| Purchase via Stripe MPP (Shared Payment Tokens, fiat-native, no browser) |
| Purchase via x402 USDC payment |
| Poll order status until complete |
| Get EPP auth code to transfer your domain away |
| Remove registrar lock for transfers |
| Renew via Stripe |
npx -y @smithery/cli@latest install @nach-dakwale/instadomain --client claudeAdd to your MCP config:
{
"mcpServers": {
"instadomain": {
"url": "https://instadomain.fly.dev/mcp/"
}
}
}Use the Streamable HTTP endpoint:
https://instadomain.fly.dev/mcp/You: Find me a domain for a coffee subscription service
Claude: Let me check some options...
coffeecrate.com - $18.12 (available)
brewbox.io - $52.49 (available)
dailygrind.co - $35.99 (available)
You: Buy coffeecrate.com
Claude: I'll need your registration details...
[collects name, email, address]
Stripe checkout created. Complete payment here:
https://checkout.stripe.com/...
Domain registered! DNS zone created on Cloudflare.
Your scoped API token: cf_...Wholesale cost + small flat markup per TLD. Examples:
TLD | Price |
.com | ~$18 |
.io | ~$52 |
.dev | ~$21 |
.co | ~$36 |
.ai | ~$99 |
Prices include 1-year registration and WHOIS privacy.
InstaDomain accepts x402 payments in USDC on Base. No signup, no API keys. Your AI agent pays directly from a wallet.
This enables fully autonomous agents to register domains without human payment intervention.
InstaDomain implements Stripe's Machine Payments Protocol so agents can pay with fiat (cards, Link) or stablecoins via Shared Payment Tokens — no browser checkout, no human in the loop.
The flow:
POST /buy/mpp to create an order — returns a pay_url.
GET /pay/mpp/{order_id} with an MPP-enabled HTTP client. The first response is HTTP 402 with a WWW-Authenticate challenge. The client mints a Shared Payment Token via the advertised Stripe Business Network profile and retries with an Authorization header. The server charges the SPT through Stripe and returns the receipt in Authentication-Info.
InstaDomain also exposes a REST API for non-MCP integrations:
GET /check/{domain} - check availability + price
POST /check - bulk check (up to 50 domains)
GET /suggest?keyword=coffee - AI-generated domain suggestions
POST /buy - initiate Stripe purchase
POST /buy/mpp - initiate MPP (Shared Payment Token) purchase
GET /pay/mpp/{order_id} - 402-paywalled endpoint (MPP)
GET /status/{order_id} - check order status
POST /renew/{order_id} - renew a domain
Full API at https://instadomain.fly.dev/docs
Do I actually own the domain? Yes. You are the legal registrant on record with OpenSRS (Tucows). InstaDomain is listed as admin/tech contact for service management, but you hold all ICANN rights. WHOIS privacy is on by default so your details stay private.
How does DNS get set up? After payment clears, InstaDomain automatically creates a Cloudflare DNS zone for your domain and returns a scoped API token. Your domain points at Cloudflare's nameservers and is ready to use. No manual configuration required on your end.
Can I transfer my domain to another registrar?
Yes, anytime. Use get_transfer_code to get your EPP auth code and unlock_domain to remove the registrar lock, then initiate the transfer at your destination registrar. Note: ICANN requires a 60-day lock after initial registration before transfers are allowed.
What if I want to manage DNS somewhere other than Cloudflare? Update the nameservers at InstaDomain's registrar panel or contact support. The Cloudflare zone is set up for convenience, not as a lock-in.
Domains are registered through OpenSRS (Tucows). You are the legal registrant. InstaDomain is listed as admin/tech contact for service management only. Full ICANN rights apply, including the right to transfer your domain at any time.
Live server: https://instadomain.fly.dev
Smithery: https://smithery.ai/servers/nach-dakwale/instadomain
xpay.tools: https://xpay.tools/instadomain
MCP endpoint: https://instadomain.fly.dev/mcp/
MIT
Start the purchase flow for an available domain via Stripe checkout.
IMPORTANT: Before calling this tool, you MUST first call check_domain to get the price, then clearly show the user the price and get their explicit confirmation before proceeding. Never call buy_domain without the user seeing and approving the price first.
The registrant contact details are required because the domain will be registered in the buyer's name (they become the legal owner). WHOIS privacy is enabled by default, so these details are not publicly visible.
Creates a Stripe checkout session. Returns a checkout URL that the user should open in their browser to complete payment securely via Stripe, plus the order ID for tracking.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to purchase (e.g. "coolstartup.com"). | |
| first_name | Yes | Registrant's first name. | |
| last_name | Yes | Registrant's last name. | |
| Yes | Registrant's email address. | ||
| address1 | Yes | Registrant's street address. | |
| city | Yes | Registrant's city. | |
| state | Yes | Registrant's state or province. | |
| postal_code | Yes | Registrant's postal/zip code. | |
| country | Yes | 2-letter ISO country code (e.g. "US", "GB", "DE"). | |
| phone | Yes | Phone number in format +1.5551234567. | |
| org_name | No | Organization name (optional, leave empty for individuals). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it creates a Stripe checkout session, returns checkout URL and order ID, explains that registrant details are required for legal ownership, and mentions WHOIS privacy. Lacks explicit statement about charging the user, but checkout session implies payment.
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?
Well-structured with clear sections: purpose, important prerequisite note, explanatory context, and return value description. Every sentence serves a purpose without being verbose.
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?
Covers prerequisites, legal implications of registrant data, payment flow, and output. Complete for a purchase tool with many parameters and no annotations.
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?
Input schema has 100% coverage, so baseline is 3. Description adds value by explaining that registrant details are needed for ownership and that WHOIS privacy hides them, providing context beyond the schema.
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?
Clearly states the tool starts a purchase flow for a domain via Stripe checkout. Distinguishes from siblings like check_domain and buy_domain_crypto by specifying the payment method and flow.
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?
Explicitly instructs to call check_domain first, show price to user, get confirmation before proceeding. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the purchase flow for a domain using USDC crypto payment (x402 protocol).
This is a 2-step process for autonomous agent payments:
Step 1: Call this tool to get an order_id and pay_url. Step 2: Make an HTTP GET request to the pay_url. Your x402-enabled HTTP client will receive an HTTP 402 response with payment requirements, then automatically pay with USDC on Base. The payment and settlement happen via the x402 protocol (no browser or human needed).
After payment, call get_domain_status(order_id) to poll until complete.
Requires: An x402-compatible HTTP client with a funded USDC wallet on Base.
The registrant contact details are required because the domain will be registered in the buyer's name (they become the legal owner). WHOIS privacy is enabled by default, so these details are not publicly visible.
IMPORTANT: Before calling this tool, you MUST first call check_domain to get the price and confirm it with the user.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to purchase (e.g. "coolstartup.com"). | |
| first_name | Yes | Registrant's first name. | |
| last_name | Yes | Registrant's last name. | |
| Yes | Registrant's email address. | ||
| address1 | Yes | Registrant's street address. | |
| city | Yes | Registrant's city. | |
| state | Yes | Registrant's state or province. | |
| postal_code | Yes | Registrant's postal/zip code. | |
| country | Yes | 2-letter ISO country code (e.g. "US", "GB", "DE"). | |
| phone | Yes | Phone number in format +1.5551234567. | |
| org_name | No | Organization name (optional, leave empty for individuals). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It describes the 2-step process, x402 payment, requirement for x402-compatible client with funded wallet, and that WHOIS privacy is enabled. It does not discuss failure modes or rate limits, but covers the essential behavioral aspects.
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 organized into clear steps and an important note. It is concise but covers necessary details. Could be slightly more streamlined, but structure aids readability.
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 tool complexity (2-step process, external HTTP call), the description provides sufficient context: prerequisites, steps, follow-up polling. It mentions outputs implicitly (order_id, pay_url) and references get_domain_status. Lacks details on output schema but functional context is adequate.
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%, so baseline is 3. The description adds context that registrant details are required because buyer becomes legal owner, but does not elaborate on individual parameters beyond schema. Score remains at baseline.
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 'Start the purchase flow for a domain using USDC crypto payment (x402 protocol).' This specifies the verb (start purchase flow), resource (domain), and payment method, distinguishing it from sibling tools like buy_domain (likely fiat).
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 explicitly says 'Before calling this tool, you MUST first call check_domain to get the price and confirm it with the user.' It also outlines the 2-step process and follow-up with get_domain_status. It does not discuss when not to use it compared to alternatives, but provides clear prerequisites and sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a domain is available for purchase and get its price.
Always call this before buy_domain. Show the user the price_display value (e.g. "$18.12") and confirm they want to proceed before buying.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The full domain name to check (e.g. "coolstartup.com"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It clearly states the tool checks availability and price (read-only). However, it does not mention error states (e.g., domain invalid, network issues) or any rate limits, but for a simple check, this is adequate.
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?
Two sentences, zero filler. The first sentence states purpose, the second gives actionable workflow. Highly concise and front-loaded.
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's simplicity (one param) and the presence of an output schema (not shown but context says it exists), the description covers all needed context: what the tool does, what parameter it takes, and what to do with the result. No gaps.
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 has 100% description coverage for the single 'domain' parameter, including example. The description adds context by specifying the parameter expects a full domain name like 'coolstartup.com', which aids correct invocation beyond schema.
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 explicitly states the tool checks domain availability and gets price, with a specific verb ('Check') and resource ('domain'). It also clearly instructs to show price to user, distinguishing its purpose from sibling tools like buy_domain or check_domains_bulk.
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 provides explicit guidance: 'Always call this before buy_domain. Show the user the price_display value and confirm they want to proceed before buying.' This tells when to use and what to do with results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check availability of up to 50 domain names in one call.
Uses fast RDAP lookups (no pricing). Returns a summary with total/available/taken counts plus per-domain details.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | List of domain names to check (max 50). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that lookups are via RDAP and do not involve pricing, and describes the return structure (summary counts and per-domain details). This gives good behavioral insight for a read-only tool.
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?
Two sentences front-load the main purpose, followed by technical detail and return format. No extraneous words; every sentence adds value.
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?
Output schema exists, so description is not required to detail return values. It mentions summary and per-domain details, which is sufficient. Lacks specifics on error handling or input validation, but overall complete for a simple tool.
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?
Input schema has 100% coverage with description for the lone parameter 'domains' (array of strings, max 50). Description reiterates 'up to 50' but adds no new meaning beyond the schema; baseline score of 3 is appropriate.
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?
Description clearly states the verb 'Check availability' and the resource 'domain names', specifying the bulk nature with 'up to 50 domain names in one call'. It distinguishes from the sibling 'check_domain' tool, which is for single domains.
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?
Implies usage for checking multiple domains at once with 'in one call'. Mentions 'Uses fast RDAP lookups (no pricing)' to clarify it's for availability only, not purchasing. No explicit alternatives or when-not-to-use, but context with siblings provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of a domain purchase order.
Polls the backend every 3 seconds (up to 120 seconds) until the order reaches a terminal state (complete or failed).
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order ID returned from buy_domain (e.g. "ord_abc123"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavioral details: polling every 3 seconds up to 120 seconds until terminal state. No annotations provided, so description carries full burden. Could mention timeout behavior or error cases.
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?
Two efficient sentences, no fluff, front-loaded with purpose and key behavioral detail.
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?
With a single parameter and output schema present (though not shown), description provides sufficient context for the tool's simple functionality.
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%, so schema alone adequately describes the order_id parameter. Description adds no extra meaning beyond the schema's description.
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?
Clearly states it gets the status of a domain purchase order, with specific polling behavior, distinguishing it from sibling tools like buy_domain or check_domain.
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?
Implies use after purchasing a domain to check order status, but lacks explicit when-not-to-use or alternatives. Context is clear enough for agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the EPP/transfer authorization code for a completed domain purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order ID of a completed domain purchase. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states the action without disclosing potential side effects, permissions needed, or constraints (e.g., code expiration). Minimal transparency beyond the basic operation.
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 a single, direct sentence that conveys the core purpose without extraneous words. Front-loaded with the action.
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 an output schema exists (not shown), the description does not need to detail return values. However, it omits mention of prerequisites (e.g., domain must be purchased and completed) and any constraints on order status, making it adequate but not complete.
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 100% description coverage for the single parameter 'order_id'. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
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 'Get the EPP/transfer authorization code for a completed domain purchase' clearly identifies the verb (get), the resource (EPP/transfer code), and the specific context (completed domain purchase). This distinguishes it from sibling tools like check_domain or get_domain_status.
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 usage when needing a transfer code for a completed order, but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, though no sibling tool directly overlaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renew a domain for 1 additional year.
Creates a Stripe checkout session for the renewal payment.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order ID of a completed domain purchase (e.g. "ord_abc123"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions creating a Stripe checkout session, indicating payment handling, but does not disclose side effects like whether it is destructive, requires authentication, or what happens if the domain is already renewed. Adequate but not comprehensive.
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 two sentences with no fluff. The first sentence states the core purpose and the second adds a key behavioral detail. Front-loaded and efficient.
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 simple tool with one parameter and an existing output schema (implied), the description is complete enough. It tells the action (renew), the duration (1 year), and the mechanism (Stripe checkout). No significant gaps.
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% with one parameter (order_id) having a description already. The tool description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate.
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 renews a domain for 1 additional year and creates a Stripe checkout session, with a specific verb and resource. It is distinct from siblings like buy_domain (purchase) and check_domain (availability).
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 usage for renewing a domain but does not explicitly state when to use or when not to use, nor does it compare to alternatives like buy_domain or extend. Context from siblings helps, but the description alone lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate domain name ideas from a keyword and check their availability.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | A keyword or short business name (e.g. "taskflow"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions generating ideas and checking availability, but does not detail what 'check their availability' means (e.g., real-time vs cached), limits on number of suggestions, or any side effects. The description is adequate but minimal.
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 a single sentence that directly communicates the tool's function. It contains no unnecessary words or repetitions, making it highly efficient.
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 one parameter and an output schema (not shown but indicated), the description is nearly complete. It would benefit from briefly noting the output format (e.g., list of domain names with availability), but current detail is sufficient for a simple tool.
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% and the description for the keyword parameter is clear. The tool description does not add additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
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 generates domain name ideas from a keyword and checks availability. It distinguishes from sibling tools like check_domain (single domain check) and check_domains_bulk (bulk check), as well as buy_domain and unlock_domain, by focusing on suggestion rather than verification or purchase.
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 usage when needing domain name suggestions from a keyword, but does not explicitly state when to use this tool over siblings like check_domain or buy_domain. No exclusion criteria or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the registrar transfer lock from a completed domain purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order ID of a completed domain purchase. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It states the mutation (removing lock) but provides no details on side effects, prerequisites, or failure cases.
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 very short and front-loaded, but could be more informative without being verbose.
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's simplicity and presence of an output schema, the description is minimally adequate, but lacks information about post-conditions or required prerequisites.
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%, so the description adds no extra meaning beyond the schema's definition of 'order_id'.
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 uses a specific verb ('Remove') and resource ('registrar transfer lock from a completed domain purchase'), clearly distinguishing it from siblings like buy_domain or check_domain.
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?
Implies usage after a completed domain purchase but does not explicitly state when not to use or provide alternative tools like get_transfer_code or check_domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
buy_domain11 fields changedInput schema / properties / address1 / descriptionAdded value: +"Registrant's street address."Input schema / properties / city / descriptionAdded value: +"Registrant's city."Input schema / properties / country / descriptionAdded value: +"2-letter ISO country code (e.g. \"US\", \"GB\", \"DE\")."Input schema / properties / domain / descriptionAdded value: +"The domain to purchase (e.g. \"coolstartup.com\")."Input schema / properties / email / descriptionAdded value: +"Registrant's email address."Input schema / properties / first_name / descriptionAdded value: +"Registrant's first name."Input schema / properties / last_name / descriptionAdded value: +"Registrant's last name."Input schema / properties / org_name / descriptionAdded value: +"Organization name (optional, leave empty for individuals)."Input schema / properties / phone / descriptionAdded value: +"Phone number in format +1.5551234567."Input schema / properties / postal_code / descriptionAdded value: +"Registrant's postal/zip code."Input schema / properties / state / descriptionAdded value: +"Registrant's state or province."buy_domain_crypto11 fields changedInput schema / properties / address1 / descriptionAdded value: +"Registrant's street address."Input schema / properties / city / descriptionAdded value: +"Registrant's city."Input schema / properties / country / descriptionAdded value: +"2-letter ISO country code (e.g. \"US\", \"GB\", \"DE\")."Input schema / properties / domain / descriptionAdded value: +"The domain to purchase (e.g. \"coolstartup.com\")."Input schema / properties / email / descriptionAdded value: +"Registrant's email address."Input schema / properties / first_name / descriptionAdded value: +"Registrant's first name."Input schema / properties / last_name / descriptionAdded value: +"Registrant's last name."Input schema / properties / org_name / descriptionAdded value: +"Organization name (optional, leave empty for individuals)."Input schema / properties / phone / descriptionAdded value: +"Phone number in format +1.5551234567."Input schema / properties / postal_code / descriptionAdded value: +"Registrant's postal/zip code."Input schema / properties / state / descriptionAdded value: +"Registrant's state or province."check_domain1 field changedInput schema / properties / domain / descriptionAdded value: +"The full domain name to check (e.g. \"coolstartup.com\")."check_domains_bulk1 field changedInput schema / properties / domains / descriptionAdded value: +"List of domain names to check (max 50)."get_domain_status1 field changedInput schema / properties / order_id / descriptionAdded value: +"The order ID returned from buy_domain (e.g. \"ord_abc123\")."get_transfer_code1 field changedInput schema / properties / order_id / descriptionAdded value: +"The order ID of a completed domain purchase."renew_domain1 field changedInput schema / properties / order_id / descriptionAdded value: +"The order ID of a completed domain purchase (e.g. \"ord_abc123\")."suggest_domains1 field changedInput schema / properties / keyword / descriptionAdded value: +"A keyword or short business name (e.g. \"taskflow\")."unlock_domain1 field changedInput schema / properties / order_id / descriptionAdded value: +"The order ID of a completed domain purchase."v1.0.0buy_domainbuy_domain_cryptocheck_domaincheck_domains_bulkget_domain_statusget_transfer_coderenew_domainsuggest_domainsunlock_domainScored across 9 tools
Each tool targets a distinct function: checking availability, purchasing via two payment methods, polling order status, retrieving transfer codes, renewing, suggesting names, and unlocking. No functional overlap.
All tools follow a consistent snake_case verb_noun pattern (e.g., check_domain, buy_domain, get_domain_status). Minor pluralization in check_domains_bulk is acceptable.
9 tools cover the domain lifecycle—check, buy, renew, unlock, transfer code, suggestions—without unnecessary redundancy. The scope is well-balanced.
Core operations (check, purchase, renew, unlock, transfer code) are present. Missing DNS management or contact update tools, but these are atypical for a basic domain registrar MCP server.
Domain registration for AI agents via Stripe or x402 crypto with Cloudflare DNS.
Domain search, registration, DNS, marketplace, and checkout with your AI agent.
Agent-first domain registration and DNS management, paid with USDC via x402.
Buy & manage domains from any AI chat: availability, register, DNS, email forwarding, AI bot stats.
