一个模型上下文协议 (MCP) 服务器，使用 IP2WHOIS API 提供全面的 WHOIS 查询功能。该服务器允许 AI 代理查询域名注册详情，包括过期日期、注册商信息和注册人数据。
域名查询：检索任何域名的详细 WHOIS 数据。
全面数据：包括域名年龄、域名服务器、注册商信息以及行政/账单联系人详情。
FastMCP 框架：基于高性能的 FastMCP Python 框架构建。
Related MCP server: Whodis MCP Server
此 MCP 服务器需要 API 密钥才能工作。您可以注册获取免费 API 密钥，每月可享受多达 500 次查询。
该设置还使用了 uv，您可以按照指南进行安装。
按照以下步骤在 Claude Desktop 中使用此 MCP 服务器：
将存储库下载到本地。
设置 uv 包管理器，您可以再次参考指南进行操作。
确保已安装 Claude Desktop。如果尚未安装，请从此处下载（适用于 Windows 和 MacOS 用户），或按照此指南（适用于 Linux 用户）。
在您选择的编辑器中打开 claude_desktop_config.json。如果您还没有该文件，请按照此指南创建一个。
将以下内容添加到您的 claude_desktop_config.json 中：
{
"mcpServers": {
"ip2whois": {
"command": "uv",
"args": [
"--directory",
"/path/to/ip2whois/src",
"run",
"server.py"
],
"env": {
"IP2WHOIS_API_KEY": "<YOUR API key HERE>"
}
}
}
}请记得将 /path/to/ip2whois 路径替换为您本地 IP2WHOIS MCP 服务器的实际路径。
要获取您的 API 密钥，只需登录到您的仪表板即可获取。将上文中的 <YOUR API key HERE> 替换为您的实际 API 密钥。
保存更改后重启 Claude Desktop，您应该会在 Search and tools 菜单中看到它。
只需在 Claude Desktop 的聊天中输入关于 IP 的查询即可。以下是一些查询示例：
(domain) 的注册商是谁？
(domain) 的所有者是谁？
(domain) 的 WHOIS 信息是什么？
例如，以下是域名 google.com 的查询结果：
在 Claude Desktop 中，模型将根据 IP2WHOIS MCP 服务器返回的结果自动生成输出。
IP2WHOIS_API_KEY
IP2WHOIS API 密钥，允许您每月免费查询多达 500 次，并获取有关 IP 地址的更多详细信息。您可以注册获取免费 API 密钥，或订阅套餐以享受更多权益。
get_whois查询域名的 WHOIS 数据。
参数：
domain (string)：要查询的域名（例如 google.com）。
输出：返回一个包含以下内容的 JSON 对象：
domain_id, status, domain_age
create_date, update_date, expire_date
registrar (名称、网址等)
registrant (姓名、组织、国家)
nameservers
请参阅 LICENSE 文件。
Lookup for the list of hosted domain names by IP address.
Args:
ip: The ip address (IPv4 or IPv6) to look up.
Returns:
A JSON string result includes the domains hosted on the ip address, and the
total number of hosted domains found.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so description carries full burden. It discloses that the tool returns a JSON string with domains and total count, but does not mention any limitations, rate limits, error handling, or data source freshness. For a simple lookup, this is adequate but not highly transparent.
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 short and includes structured Args/Returns sections. It is clear and to the point, though the Returns section could be more concise.
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?
For a simple tool with one parameter and no nested objects, the description covers the essential behavior. The presence of an output schema (even if not detailed here) reduces the need to explain return values further.
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 0%, but the description adds clear meaning to the single required parameter 'ip', specifying it expects an IPv4 or IPv6 address. This significantly helps an agent understand what to provide.
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 is a lookup for hosted domain names by IP address. The verb 'Lookup' and resource 'hosted domain names' are specific, and it distinguishes from sibling tool 'get_whois' which does WHOIS lookups.
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 context (reverse DNS lookups) but does not explicitly state when to use this tool versus alternatives. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lookup WHOIS data for a domain name. Use this tool when the user asks about
domain registration details, registrar names, expiry dates, domain ownership,
or nameservers for a specific website (e.g., 'google.com').
Args:
domain: The domain name to look up (e.g., 'example.com').
Returns:
A JSON string result includes domain age, update and expiry date, assiociated nameservers, registrar and registrant information, and admin, tech and billing information.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the return format and fields, indicating it is a read-only lookup, but does not mention error handling or authorization needs.
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 concise with an effective structure: purpose statement, Args, Returns. Every sentence adds value with no waste.
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 is simple with one parameter and an output schema, the description covers parameter and return data well. It lacks mention of errors or limitations, but is otherwise 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 domain parameter is clearly described with purpose and an example. Schema has no description (0% coverage), so the description fully compensates by explaining what the parameter is.
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 performs a WHOIS lookup for a domain name, listing specific details like registrar, expiry, nameservers, etc. It is distinct from the sibling tool get_hosted_domains by focusing on registration data.
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 says when to use this tool: when user asks about domain registration details, registrar, expiry, etc. However, it does not mention when not to use or differentiate from the sibling tool.
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.
v1.2.0get_hosted_domainsget_whoisv1.1.0get_whoisv0.1.0get_whoisScored across 2 tools
The two tools have clearly distinct purposes: one resolves IP addresses to hosted domains, the other retrieves WHOIS data for domain names. There is no functional overlap.
Both tools follow the consistent verb_noun pattern (get_hosted_domains, get_whois), making the naming predictable and easy to understand.
With only two tools, the server feels minimal for the domain of IP and domain information. While the tools cover core functionalities, the count is at the lower boundary of what's reasonable.
The tools cover hosted domains and WHOIS lookups, but common related operations like IP geolocation, domain availability checks, or reverse IP lookups are missing. The surface is functional but not comprehensive.
WHOIS/RDAP lookup, IP geolocation and Punycode conversion. 1400+ TLDs incl. IDN. No API key.
Domain intel for AI agents: RDAP registration, DNS, email deliverability, tech stack.
Domain intel for AI agents: RDAP registration, DNS, email deliverability, tech stack.
Free MCP server: 36 security & dev API tools -- WHOIS, DNS, CVE, IP reputation, Cosmos SDK.