为 AI 智能体提供的域名注册服务。 无需离开终端，即可检查可用性、购买域名并配置 DNS。
InstaDomain 是一个 MCP 服务器，允许 AI 编码助手（如 Claude Code、Cursor、Windsurf）代表您注册域名。支持使用 Stripe Checkout、Stripe MPP（通过共享支付令牌的机器支付协议）或 x402（Base 链上的 USDC）进行支付。域名将以您的名义注册，并自动配置 Cloudflare DNS。
当您在 Claude Code 中构建项目时，需要一个域名。通常您需要切换到 Namecheap，搜索、加入购物车、填写表格、配置 DNS。这会浪费 10 分钟的时间在上下文切换上。
使用 InstaDomain，您的 AI 智能体可以在一次对话中检查可用性、向您展示价格并完成购买。在您完成下一个提示词之前，DNS 就已经准备就绪了。
Related MCP server: Bloomfilter
检查域名 - 检查单个域名的价格，批量检查最多 50 个域名，或获取 AI 生成的建议
购买域名 - 支持 Stripe 结账（银行卡）、Stripe MPP（通过共享支付令牌实现自动法币支付）或 x402（Base 链上的 USDC，无需注册）
自动 DNS - 创建 Cloudflare 区域并返回作用域 API 令牌给您
您的域名，您的名义 - 注册为您的财产，而非我们的
随时转出 - 内置 EPP 授权码和域名解锁功能
自动续费 - 默认开启，通过 Stripe 续费
WHOIS 隐私 - 默认开启
工具 | 功能描述 |
| 检查单个域名的可用性及价格 |
| 一次性检查最多 50 个域名 |
| 为关键词生成并检查域名建议 |
| 通过 Stripe 结账购买 |
| 通过 Stripe MPP 购买（共享支付令牌，原生法币，无需浏览器） |
| 通过 x402 USDC 支付购买 |
| 轮询订单状态直到完成 |
| 获取 EPP 授权码以转出您的域名 |
| 解除注册商锁定以便转出 |
| 通过 Stripe 续费 |
npx -y @smithery/cli@latest install @nach-dakwale/instadomain --client claude添加到您的 MCP 配置中：
{
"mcpServers": {
"instadomain": {
"url": "https://instadomain.fly.dev/mcp/"
}
}
}使用可流式传输的 HTTP 端点：
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_...批发成本 + 每个 TLD 的少量固定加价。示例：
TLD | 价格 |
.com | ~$18 |
.io | ~$52 |
.dev | ~$21 |
.co | ~$36 |
.ai | ~$99 |
价格包含 1 年注册费和 WHOIS 隐私保护。
InstaDomain 接受 Base 链上的 USDC 进行 x402 支付。无需注册，无需 API 密钥。您的 AI 智能体直接从钱包支付。
这使得完全自主的智能体能够在无需人工干预的情况下注册域名。
InstaDomain 实现了 Stripe 的机器支付协议 (MPP)，因此智能体可以使用法币（银行卡、Link）或通过共享支付令牌的稳定币进行支付——无需浏览器结账，无需人工参与。
流程：
POST /buy/mpp 创建订单 — 返回 pay_url。
使用支持 MPP 的 HTTP 客户端 GET /pay/mpp/{order_id}。首次响应为 HTTP 402，包含 WWW-Authenticate 质询。客户端通过声明的 Stripe 商业网络配置文件生成共享支付令牌，并携带 Authorization 头重试。服务器通过 Stripe 收取 SPT 并返回 Authentication-Info 中的收据。
InstaDomain 还为非 MCP 集成提供了 REST API：
GET /check/{domain} - 检查可用性及价格
POST /check - 批量检查（最多 50 个域名）
GET /suggest?keyword=coffee - AI 生成的域名建议
POST /buy - 发起 Stripe 购买
POST /buy/mpp - 发起 MPP（共享支付令牌）购买
GET /pay/mpp/{order_id} - 402 付费墙端点 (MPP)
GET /status/{order_id} - 检查订单状态
POST /renew/{order_id} - 续费域名
完整 API 文档请访问 https://instadomain.fly.dev/docs
域名通过 OpenSRS (Tucows) 注册。您是法定注册人。InstaDomain 仅作为管理/技术联系人进行服务管理。适用完整的 ICANN 权利，包括随时转出域名的权利。
实时服务器: https://instadomain.fly.dev
Smithery: https://smithery.ai/servers/nach-dakwale/instadomain
MCP 端点: 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.
