Registro de dominios para agentes de IA. Comprueba la disponibilidad, compra dominios y configura el DNS sin salir de tu terminal.
InstaDomain es un servidor MCP que permite a los asistentes de programación por IA (Claude Code, Cursor, Windsurf) registrar dominios en tu nombre. Paga con Stripe Checkout, Stripe MPP (Protocolo de Pagos para Máquinas mediante Tokens de Pago Compartidos) o x402 (USDC en Base). Los dominios se registran a tu nombre con el DNS de Cloudflare configurado automáticamente.
Estás creando un proyecto en Claude Code. Necesitas un dominio. Hoy en día, haces alt-tab a Namecheap, buscas, añades al carrito, rellenas formularios, configuras el DNS. Eso son 10 minutos de cambio de contexto.
Con InstaDomain, tu agente de IA comprueba la disponibilidad, te muestra el precio y lo compra en una sola conversación. El DNS está listo antes de que termines tu siguiente prompt.
Related MCP server: Bloomfilter
Comprobar dominios - dominio único con precio, comprobación masiva de hasta 50, o sugerencias generadas por IA
Comprar dominios - Stripe checkout (tarjeta), Stripe MPP (fiat autónomo mediante Tokens de Pago Compartidos) o x402 (USDC en Base, no requiere registro)
DNS automático - zona de Cloudflare creada con token de API con alcance limitado devuelto a ti
Tu dominio, tu nombre - registrado como tu propiedad, no la nuestra
Transferencia en cualquier momento - códigos de autorización EPP y desbloqueo de dominio integrados
Renovación automática - habilitada por defecto, renueva a través de Stripe
Privacidad WHOIS - habilitada por defecto
Herramienta | Qué hace |
| Comprueba disponibilidad + precio para un solo dominio |
| Comprueba hasta 50 dominios a la vez |
| Genera y comprueba ideas de nombres de dominio para una palabra clave |
| Compra a través de Stripe checkout |
| Compra a través de Stripe MPP (Tokens de Pago Compartidos, fiat-nativo, sin navegador) |
| Compra a través de pago x402 USDC |
| Consulta el estado del pedido hasta que se complete |
| Obtén el código de autorización EPP para transferir tu dominio fuera |
| Elimina el bloqueo del registrador para transferencias |
| Renueva a través de Stripe |
npx -y @smithery/cli@latest install @nach-dakwale/instadomain --client claudeAñade a tu configuración de MCP:
{
"mcpServers": {
"instadomain": {
"url": "https://instadomain.fly.dev/mcp/"
}
}
}Usa el endpoint HTTP Streamable:
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_...Coste mayorista + pequeño margen fijo por TLD. Ejemplos:
TLD | Precio |
.com | ~$18 |
.io | ~$52 |
.dev | ~$21 |
.co | ~$36 |
.ai | ~$99 |
Los precios incluyen el registro por 1 año y la privacidad WHOIS.
InstaDomain acepta pagos x402 en USDC en Base. Sin registro, sin claves API. Tu agente de IA paga directamente desde una billetera.
Esto permite a los agentes totalmente autónomos registrar dominios sin intervención de pago humana.
InstaDomain implementa el Protocolo de Pagos para Máquinas de Stripe para que los agentes puedan pagar con fiat (tarjetas, Link) o stablecoins mediante Tokens de Pago Compartidos — sin checkout en el navegador, sin humanos en el proceso.
El flujo:
POST /buy/mpp para crear un pedido — devuelve una pay_url.
GET /pay/mpp/{order_id} con un cliente HTTP habilitado para MPP. La primera respuesta es HTTP 402 con un desafío WWW-Authenticate. El cliente acuña un Token de Pago Compartido a través del perfil de Stripe Business Network anunciado y reintenta con una cabecera Authorization. El servidor cobra el SPT a través de Stripe y devuelve el recibo en Authentication-Info.
InstaDomain también expone una API REST para integraciones que no son MCP:
GET /check/{domain} - comprobar disponibilidad + precio
POST /check - comprobación masiva (hasta 50 dominios)
GET /suggest?keyword=coffee - sugerencias de dominio generadas por IA
POST /buy - iniciar compra en Stripe
POST /buy/mpp - iniciar compra MPP (Token de Pago Compartido)
GET /pay/mpp/{order_id} - endpoint con muro de pago 402 (MPP)
GET /status/{order_id} - comprobar estado del pedido
POST /renew/{order_id} - renovar un dominio
API completa en https://instadomain.fly.dev/docs
Los dominios se registran a través de OpenSRS (Tucows). Tú eres el registrante legal. InstaDomain aparece como contacto administrativo/técnico solo para la gestión del servicio. Se aplican todos los derechos de ICANN, incluido el derecho a transferir tu dominio en cualquier momento.
Servidor en vivo: https://instadomain.fly.dev
Smithery: https://smithery.ai/servers/nach-dakwale/instadomain
Endpoint 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.
