DomainRoc MCP Server
The server provides a single public domain-check tool; it does not expose account, payment, or domain-management operations in this schema.
Check a fully-qualified domain's confirmed availability and first-year USDT price preview.
Accept IDN domains in
xn--ASCII form.Return
unknownwhen upstream fails, restricts the domain, or requires manual review.It does not create orders, charge accounts, or register domains.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@DomainRoc MCP Servercheck if mynewbrand.com is available and what the USDT price is"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
DomainRoc Agent MCP
DomainROC — crypto-native domain registrar: register and manage domains with USDT, operable by AI agents via MCP.
Connect an MCP-compatible AI assistant to domain search and your authorized account services. Public domain search works without an account. Account services require a connection key created in Dashboard → Agent MCP on a site running the account-service update.
The optional local adapter retains these original tools. The hosted remote service additionally provides complete individual management described below.
Tool | What you can do | Permission |
| Check domain availability and a first-year USDT price preview | Public |
| View available and reserved balance | Balance and billing |
| View wallet transactions | Balance and billing |
| View your domains, expiry and renewal preferences | Domains |
| Track domain orders and payments | Orders |
| View monitoring results and service expiry | Monitoring |
| View available USDT payment networks | Balance and billing |
| Create a recharge checkout | Recharge |
| Track your recharge and balance credit | Recharge |
Recharges require the user to pay at checkout. The local adapter cannot transfer funds, withdraw, buy or renew domains, change DNS, or grant permissions. The hosted remote service supports individually authorized purchases, renewals and changes, with a separate balance-payment permission and ceiling. Prices from public search are previews, not checkout commitments.
Connect your assistant — no installation
Site | Remote MCP URL | Account page |
DomainROC |
| |
Namepopo |
|
Add the URL in your assistant's remote MCP settings. Use a connection key if your client supports bearer authentication, or complete website sign-in and consent when prompted. Never put a key in the URL or a chat message.
Codex and bearer-capable clients: copy the URL, create a key on the account page and enter it in the client's authentication field. If a header is required, use
Authorization: Bearer YOUR_CONNECTION_KEY. In Codex configuration useurlandbearer_token_env_varorhttp_headersas documented by Codex.ChatGPT: add a custom MCP with the server URL and OAuth sign-in, then select the operations on the website. ChatGPT does not accept a custom connection key for authenticated MCP; availability depends on the account's custom-MCP feature. See official authentication guidance.
Grok / Grok Bot: use New Connector → Custom, supply the URL and complete authentication. See official connector guidance. Exact Bot entry points depend on its client.
Muse.ai: add an MCP connection and enter the service URL and connection key. Keep the key in connection settings, never in chat.
The original account operations are individually authorized: view balance, wallet transactions, domains and expiry, domain orders, existing monitoring, payment networks, create recharge, and check recharge credit. Creating a recharge does not imply permission to view other wallet data. Choose a per-checkout amount ceiling (new connections default to 100 USDT), a lifetime of up to 90 days, and revoke or reduce permissions anytime. Adding permissions requires a fresh connection and consent.
The website hosts the remote service using the official MCP SDK's stateless Streamable HTTP transport. OAuth uses PKCE, short-lived access tokens and rotating refresh tokens tied to the same revocable account connection. The original package in this repository remains available for existing local integrations; ordinary remote users do not install it.
Use separate accounts and grants for the two sites. Public search is also available directly on each website without connecting an account. The authenticated remote endpoint requires a key or OAuth even for its domain-search tool.
Examples: “When do my domains expire?”, “Show my available USDT balance”, “Create a 20 USDT recharge using the network I selected.”
Related MCP server: Domain Checker MCP Server
Recharge reliability
Select a supported network using get_payment_methods, obtain the user's choice of amount and network, then call create_recharge. Supply a unique request_id of 8–64 letters, digits, underscores or hyphens for each intended recharge. Reuse that same ID and parameters on every retry, especially after a timeout. Changed parameters under the same ID are rejected. Reconnects should use existing recharge numbers rather than generating replacement orders.
A checkout URL or payment_status alone does not establish wallet credit. Only a populated credited_at from get_recharge confirms credit. Settlement, signatures, callbacks and once-only balance credit remain the website's existing wallet responsibility.
Limits and privacy
Keys are scoped to one account and expire; users and administrators can revoke them.
Servers store a key hash, never the full key. Activity records exclude keys and tool payloads.
Account services admit at most 30 requests per connection per minute, backed by the website database; other site limits also apply.
List tools support
limit(1–100) andoffset.Public domain search retains its per-process 5/minute, 200/day budget and 45-second result cache; public search is outside account activity statistics.
HTTPS targets are fixed; redirects and inherited proxy settings are disabled. Network errors remain unconfirmed.
Development
uv sync --extra dev
uv run --frozen pytest -q
python examples/demo_stdio.py --domain example.comAutomated tests use mocked HTTP and never submit real payments or registrations. The demo performs a live public lookup only. Historical demo evidence refers to the original search release, not the new account tools.
MIT.
Individual remote management
The hosted remote server exposes 106 tools, including individually authorized domain, VPS, proxy, monitoring and wallet operations. Use the website permission picker to select exact actions. Balance payment is a separate permission with a per-operation ceiling; automatic renewal follows separately disclosed website rules. Sensitive credentials require fresh website verification. Every changing operation uses a stable request reference to prevent duplicate execution. The optional local adapter retains its smaller legacy tool set; use the remote URL for complete management.
远程服务支持按单项授权的域名、VPS、代理、监控及钱包操作。余额付款需单独授权并设置单次上限;自动续费按另行确认的官网规则执行。敏感资料需在官网验证身份,变更操作使用固定编号防止重复执行。完整管理请使用远程服务链接,本地可选适配器保留原有精简工具。
Available Tools
1 toolcheck_domainAInspect
Check a single domain's confirmed availability and first-year USDT preview price.
Input: a fully-qualified DNS domain, e.g. example.com (IDN in xn-- ASCII form). Returns unknown if upstream fails, restricts the domain, or requires manual review. Does not create orders, charge accounts, or register domains.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it declares the tool is side-effect free (no orders, no charges, no registration) and discloses the failure mode — 'unknown' when upstream fails, restricts the domain, or requires manual review. It omits auth/rate-limit context, which keeps it below a 5.
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?
Four short sentences, front-loaded with the core capability, then input format, then return/failure semantics, then the negative scope. Every sentence carries distinct information and none restate the tool name or schema.
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?
There is no output schema, so the description must describe results — and it does, covering both the success payload (availability + first-year USDT price) and the 'unknown' fallback condition. For a single-parameter read-only lookup, nothing an agent needs before calling is missing.
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 single parameter has 0% schema description coverage, so the description must compensate, and it does: it specifies a fully-qualified DNS domain, gives 'example.com' as a concrete example, and notes IDN must be in xn-- ASCII form. That is real format guidance beyond the bare 'domain' string type, though it doesn't cover edge cases like trailing dots or length limits.
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?
States a precise verb and resource ('Check a single domain') and names exactly what it returns: confirmed availability plus a first-year USDT preview price. The 'single domain' scope and the negative clause ('Does not create orders, charge accounts, or register domains') make the boundary against ordering tools unmistakable even though no siblings are listed.
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 makes the use case clear (pre-purchase availability/price lookup) and explicitly rules out adjacent operations by stating it does not create orders, charge accounts, or register domains. It stops short of naming a companion ordering tool or stating prerequisites, but the when/when-not split is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
check_domain
TDQS
Scored across 1 tool
Only one tool is present, so there is no overlap or possibility of misselection. Its purpose is clearly stated as checking a single domain's availability and price.
The single tool name check_domain follows a clear verb_noun convention. With only one tool, there is no inconsistency in style or pattern.
The server has only one tool, which is thin even for a focused domain-availability service. It is arguably sufficient for the narrow stated purpose, but the surface feels under-scoped.
The core single-domain availability check is covered, but notable adjacent operations such as bulk checks, TLD exploration, or richer domain lookup are absent. The tool explicitly excludes order creation and registration, so lifecycle coverage is intentionally incomplete.
Maintenance
Related MCP Connectors
Domain availability search, WHOIS lookup, TLD pricing and registry rules from name.ai. Read-only.
Domain search, registration, DNS, marketplace, and checkout with your AI agent.
Check domain availability and prices, and look up any domain's public records. Read-only.
Find, register, and manage domains from any AI chat or agent
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables AI agents to perform WHOIS lookups to retrieve domain registration details, including ownership, registration dates, and availability status without requiring browser searches.462 npm21MIT
- AlicenseAqualityDmaintenanceEnables AI agents to check domain availability, perform batch domain lookups, and generate intelligent domain name suggestions across multiple TLDs using WHOIS integration.3MIT
- AlicenseAqualityCmaintenanceConfidence-scored domain availability checking for AI agents via real-time DNS and WHOIS lookups. Bulk check up to 100 domains, WHOIS enrichment, and quota monitoring. All tools are read-only.31MIT
- AlicenseAqualityDmaintenanceEnables AI agents to perform real-time WHOIS and RDAP lookups, domain availability checks, and TLD infrastructure exploration using native protocols without API keys.8MIT