Rdap

@pipeworx/rdap

RDAP MCP——用于查询域名、IP、ASN 和名称服务器的注册数据访问协议。它是 WHOIS 的结构化 JSON 后继协议，由注册局自己的服务提供答复。无需密钥。

属于 Pipeworx——连接 AI Agent 与 1683+ 个实时数据源的 MCP 网关。

工具

• domain(name | domain, base?) — 域名注册记录：注册商、注册／到期日期、名称服务器、状态。注册局返回 404 是一个答复，而非错误——结果为 {registered: false}，这正是批量检查可用性的关键。
• ip(address | ip) — IP／网段分配记录
• asn(number) — ASN 分配记录
• entity(handle, base?) — 根据句柄查询注册局实体（例如注册人 ID）
• nameserver(host, base?) — 名称服务器（粘合记录），适用于注册局支持的情况

身份验证

无。查询的所有端点都是公开的注册局 RDAP 服务。

TLD 覆盖范围——以及 IANA 引导文件中的缺漏

服务器发现通常通过 IANA RDAP 引导文件 （https://data.iana.org/rdap/dns.json，缓存 24h）进行。**该文件并不完整。**截至 2026-07-23 发布时，文件列出了 1,438 个已委派 TLD 中的 1,200 个；遗漏的 238 个几乎 全是从未向 IANA 注册 RDAP 端点的 ccTLD。根据 2026-08-30 的 Majestic Million 数据， 这 238 个 TLD 占全球链接数最多的域名的 23.4%——包括 .io、.de、.us、.me 和 .ru。

因此，此工具包附带 FALLBACK_BASES（参见 src/index.ts）：适用于 IANA 遗漏 TLD 的注册局 RDAP 端点。仍会优先查询 IANA，因此注册局在上游添加后，这张映射表便会自行失效。目前除 IANA 外覆盖：

基址	TLD
rdap.identitydigital.services/rdap	.ac .ag .bz .gi .io .lc .me .mn .sc .sh .vc
rdap.denic.de	.de
rdap.nic.ch / rdap.nic.li	.ch .li
rdap.nic.us	.us
rdap.nic.kz	.kz
rdap.sgnic.sg/rdap	.sg
rdap.mynic.my/rdap	.my
rdap.website.ws	.ws

向该映射表添加 TLD 前——请先阅读。通过请求 <base>/domain/<a-name-you-know-is-REGISTERED> 进行验证，并要求得到包含真实记录的 HTTP 200 响应。rdap.identitydigital.services 会为其不提供服务的 TLD 返回格式正确的 RDAP 404，因此无法区分这里的 404 究竟表示服务不支持该 TLD，还是“此域名尚未注册”。 因此，错误的基址不会触发错误——它会将该 TLD 中所有已注册域名都报告为可用。这正是此工具包旨在避免的问题。

许多 ccTLD 根本没有公开的 RDAP 服务。根据 2026-08-30 的探测结果，.ru、.it、.eu、.se 和 .co 的常见 rdap.* 主机名无法解析（NXDOMAIN），因此映射表中无从添加这些 TLD。对于这些 TLD， domain 会返回 {found: false, reason: "tld_not_in_iana_bootstrap"}，并附带说明缺漏在于 IANA 而非我们自己的消息，以及一个 hint：如果知道注册局自己的端点，可将其作为 base 传入；否则请使用该注册局的 WHOIS 页面。此处刻意不抛出错误——上游注册局的缺漏并非 Pipeworx 的缺陷，不应被记录为此类问题。

数据源

• IANA RDAP 引导文件：https://data.iana.org/rdap/dns.json（以及 ipv4、ipv6、asn）
• IANA 已委派 TLD 列表：https://data.iana.org/TLD/tlds-alpha-by-domain.txt
• 通过上述引导文件访问的各个 RIR／注册局 RDAP 服务

快速开始

添加到 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "rdap": {
      "url": "https://gateway.pipeworx.io/rdap/mcp"
    }
  }
}

此端点实际提供的内容

https://gateway.pipeworx.io/rdap/mcp 上的 tools/list 会返回上表中的工具，以及 Pipeworx 共享元工具——ask_pipeworx、 discover_tools、search_within、remember/recall 及网关范围内的其他工具。因此，你看到的工具数量会多于表中的数量：目前，单个工具包端点除了列出该工具包自身的工具外，还会列出约 30 个共享工具。连接的 initialize 响应会说明其确切范围，是当天情况的权威说明。

这是有意设计的，并非意外多路复用。元工具让限定范围的连接也能回答该工具包无法覆盖的问题——通过 ask_pipeworx 在整个目录中路由——无需再添加第二个 MCP 服务。目前无法在不包含这些工具的情况下挂载工具包端点；如果额外的架构定义占用的上下文超过了路由带来的收益，请连接一次完整网关，而不是连接多个工具包端点。

或者，连接完整的 Pipeworx 网关，直接列出所有工具包的工具，而不只是此工具包的工具：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

两个 URL 都连接到同一个网关和相同的 1683+ 个数据源。唯一的区别是直接列出哪个工具包的工具；无论连接哪一个，ask_pipeworx 都能访问所有工具。

没有 MCP 客户端？通过 HTTP 调用

curl -X POST https://gateway.pipeworx.io/v1/tools/rdap_domain \
  -H 'Content-Type: application/json' \
  -d '{"name":"example.com"}'

首次调用无需账户。查看任意工具：GET https://gateway.pipeworx.io/v1/tools/rdap_domain。查找工具：使用 {"query":"..."} 向 https://gateway.pipeworx.io/v1/tools/search_packs 发送 POST 请求。

独立运行（无需网关账户）

此软件包也可以作为本地 stdio MCP 服务运行——无需 Pipeworx 账户，也无需经过网关：

{
  "mcpServers": {
    "rdap": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-rdap"]
    }
  }
}

或者直接运行它，以确认服务能够启动：

npx -y @pipeworx/mcp-rdap

它通过 stdin/stdout 使用 MCP，并响应 initialize/tools/list/tools/call，仅提供此工具包的工具，不包含上述网关连接额外提供的任何共享元工具。源代码和工具相同，但没有 ask_pipeworx 路由。

使用 ask_pipeworx

你可以用通俗的英语提问，而不是直接调用工具——此方式既适用于上文的工具包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Rdap data" })

网关会自动选择合适的工具并填入参数。

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT