Domainregistrierung für KI-Agenten. Prüfen Sie die Verfügbarkeit, kaufen Sie Domains und konfigurieren Sie DNS, ohne Ihr Terminal zu verlassen.
InstaDomain ist ein MCP-Server, mit dem KI-Coding-Assistenten (Claude Code, Cursor, Windsurf) in Ihrem Namen Domains registrieren können. Bezahlen Sie mit Stripe Checkout, Stripe MPP (Machine Payments Protocol via Shared Payment Tokens) oder x402 (USDC auf Base). Domains werden auf Ihren Namen registriert und Cloudflare-DNS wird automatisch konfiguriert.
Sie entwickeln ein Projekt in Claude Code. Sie benötigen eine Domain. Heute wechseln Sie per Alt-Tab zu Namecheap, suchen, legen in den Warenkorb, füllen Formulare aus und konfigurieren DNS. Das sind 10 Minuten Kontextwechsel.
Mit InstaDomain prüft Ihr KI-Agent die Verfügbarkeit, zeigt Ihnen den Preis und kauft die Domain in einem einzigen Gespräch. Das DNS ist bereit, bevor Sie Ihren nächsten Prompt beenden.
Related MCP server: Bloomfilter
Domains prüfen - einzelne Domain mit Preis, Massenprüfung von bis zu 50 Domains oder KI-generierte Vorschläge
Domains kaufen - Stripe Checkout (Karte), Stripe MPP (autonome Fiat-Zahlung via Shared Payment Tokens) oder x402 (USDC auf Base, keine Registrierung erforderlich)
Automatisches DNS - Cloudflare-Zone wird erstellt und ein API-Token mit eingeschränkten Rechten an Sie zurückgegeben
Ihre Domain, Ihr Name - als Ihr Eigentum registriert, nicht als unseres
Jederzeit wegtransferieren - EPP-Auth-Codes und Domain-Entsperrung integriert
Automatische Verlängerung - standardmäßig aktiviert, Verlängerung via Stripe
WHOIS-Datenschutz - standardmäßig aktiviert
Tool | Was es tut |
| Verfügbarkeit + Preis für eine einzelne Domain prüfen |
| Bis zu 50 Domains gleichzeitig prüfen |
| Domainnamen-Ideen für ein Keyword generieren und prüfen |
| Kauf via Stripe Checkout |
| Kauf via Stripe MPP (Shared Payment Tokens, Fiat-nativ, kein Browser) |
| Kauf via x402 USDC-Zahlung |
| Bestellstatus abfragen, bis er abgeschlossen ist |
| EPP-Auth-Code abrufen, um Ihre Domain wegzutransferieren |
| Registrar-Sperre für Transfers entfernen |
| Verlängerung via Stripe |
npx -y @smithery/cli@latest install @nach-dakwale/instadomain --client claudeFügen Sie dies zu Ihrer MCP-Konfiguration hinzu:
{
"mcpServers": {
"instadomain": {
"url": "https://instadomain.fly.dev/mcp/"
}
}
}Verwenden Sie den Streamable HTTP-Endpunkt:
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_...Großhandelskosten + kleiner pauschaler Aufschlag pro TLD. Beispiele:
TLD | Preis |
.com | ~18 $ |
.io | ~52 $ |
.dev | ~21 $ |
.co | ~36 $ |
.ai | ~99 $ |
Die Preise beinhalten 1 Jahr Registrierung und WHOIS-Datenschutz.
InstaDomain akzeptiert x402-Zahlungen in USDC auf Base. Keine Registrierung, keine API-Keys. Ihr KI-Agent zahlt direkt aus einem Wallet.
Dies ermöglicht es vollautonomen Agenten, Domains ohne menschliches Eingreifen bei der Zahlung zu registrieren.
InstaDomain implementiert das Machine Payments Protocol von Stripe, sodass Agenten mit Fiat (Karten, Link) oder Stablecoins via Shared Payment Tokens bezahlen können – kein Browser-Checkout, kein Mensch in der Schleife.
Der Ablauf:
POST /buy/mpp, um eine Bestellung zu erstellen – gibt eine pay_url zurück.
GET /pay/mpp/{order_id} mit einem MPP-fähigen HTTP-Client. Die erste Antwort ist HTTP 402 mit einer WWW-Authenticate-Challenge. Der Client erstellt ein Shared Payment Token über das beworbene Stripe Business Network-Profil und wiederholt die Anfrage mit einem Authorization-Header. Der Server belastet das SPT über Stripe und gibt die Quittung in Authentication-Info zurück.
InstaDomain stellt auch eine REST-API für Nicht-MCP-Integrationen bereit:
GET /check/{domain} - Verfügbarkeit + Preis prüfen
POST /check - Massenprüfung (bis zu 50 Domains)
GET /suggest?keyword=coffee - KI-generierte Domainvorschläge
POST /buy - Stripe-Kauf initiieren
POST /buy/mpp - MPP-Kauf (Shared Payment Token) initiieren
GET /pay/mpp/{order_id} - 402-zahlpflichtiger Endpunkt (MPP)
GET /status/{order_id} - Bestellstatus prüfen
POST /renew/{order_id} - Domain verlängern
Vollständige API unter https://instadomain.fly.dev/docs
Domains werden über OpenSRS (Tucows) registriert. Sie sind der rechtliche Registrant. InstaDomain ist nur für das Service-Management als Admin/Tech-Kontakt gelistet. Es gelten die vollen ICANN-Rechte, einschließlich des Rechts, Ihre Domain jederzeit zu transferieren.
Live-Server: https://instadomain.fly.dev
Smithery: https://smithery.ai/servers/nach-dakwale/instadomain
MCP-Endpunkt: 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.
