AI 에이전트를 위한 도메인 등록 서비스. 터미널을 떠나지 않고도 도메인 가용성을 확인하고, 구매하며, DNS를 구성하세요.
InstaDomain은 AI 코딩 어시스턴트(Claude Code, Cursor, Windsurf)가 사용자를 대신하여 도메인을 등록할 수 있게 해주는 MCP 서버입니다. 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 claudeMCP 설정에 추가하세요:
{
"mcpServers": {
"instadomain": {
"url": "https://instadomain.fly.dev/mcp/"
}
}
}Streamable 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의 기계 결제 프로토콜(Machine Payments Protocol)을 구현하여 에이전트가 법정화폐(카드, Link) 또는 공유 결제 토큰을 통한 스테이블코인으로 결제할 수 있도록 합니다. 브라우저 결제나 인간의 개입이 필요 없습니다.
흐름:
POST /buy/mpp를 호출하여 주문을 생성하면 pay_url이 반환됩니다.
MPP가 활성화된 HTTP 클라이언트로 GET /pay/mpp/{order_id}를 호출합니다. 첫 번째 응답은 WWW-Authenticate 챌린지가 포함된 HTTP 402입니다. 클라이언트는 광고된 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.
