IPIPAI MCP Server 正式发布：AI 大模型现在可以直接调用 IP 情报工具

引言：从 REST API 到原生 MCP

在过去，如果你想让 AI 大模型查询 IPIPAI 的 IP 情报，只有一种方式：写胶水代码调用 REST API，解析 JSON，再把需要的字段喂给模型。这种方式能用，但抽象层次不对。模型无法自己发现有哪些工具可用，无法自己读取参数定义，而且每次 IPIPAI 新增能力，你都要更新集成代码、重新部署、再向模型重新解释新工具。

今天这一切改变了。IPIPAI 正式发布完整的 MCP（Model Context Protocol）Server，使用 JSON-RPC 2.0 协议，通过 Streamable HTTP 传输。Claude、ChatGPT、Gemini、Cursor 以及任何实现了 MCP 规范的客户端，现在都可以连接到 https://ipipai.com/mcp，调用 tools/list 发现全部 11 个可用工具，然后调用 tools/call 执行任意一个——全程不需要写一行集成代码，不需要 API Key，不需要先翻阅任何文档。

这是 AI 大模型消费网络情报方式的一次重要转变。模型不再需要人类预先编写函数定义，而是在运行时自行发现工具、读取描述和输入 schema、根据用户问题决定调用哪个工具，并接收可以推理的结构化数据。MCP Server 充当翻译器：它接收 JSON-RPC 工具调用请求，将其翻译为内部 REST API 请求，从数据库、MMDB 文件和外部 API 获取数据，然后返回模型可以理解的结构化响应。

本文将全面介绍：MCP 是什么以及为什么重要、IPIPAI MCP Server 的三层架构、两种接入方式（MCP 给 AI 大模型、REST API 给程序员）、完整的 JSON-RPC 交互流程、11 个工具的参数与使用场景、端到端实际示例、OpenIPAPI 集成，以及现有 @ipipai/sdk 与新 MCP Server 的关系。

MCP Server 与 SDK 发布的区别是什么？

@ipipai/sdk（详见我们的上一篇文章）是程序员使用的 HTTP 客户端，封装了 REST API。MCP Server 是独立的协议层：它不替代 SDK 或 REST API，而是新增了一个符合标准的 JSON-RPC 接口，让 AI 大模型可以自行发现和调用工具。程序员继续使用 SDK 和 REST API；AI 大模型使用 MCP。

现在就可以体验：打开 IPIPAI 对示例 IP 的检测报告（或访问 ipipai.com 检测任意地址），你就能在浏览器里看到这些 MCP 工具返回的同样数据——地理位置、ISP、ASN、IP 类型和 0–100 分风险评分——在连接大模型之前先直观感受一下。

什么是 MCP（Model Context Protocol）？

Model Context Protocol 是一个开放标准，定义了 AI 大模型如何与外部工具和数据源通信。它的出现是为了解决每个 Agent 开发者都遇到过的问题：每个工具集成都是一次性的。你写一个函数，为它编写 JSON schema，注册到模型运行时中，当工具发生变化时再把整个过程重来一遍。把这件事乘以几十个工具和几十个模型，集成面就变得不可管理。

MCP 用一个统一的标准化协议取代了这种临时拼凑。它不再让每个模型厂商发明自己的工具调用格式，而是定义了一种基于 JSON-RPC 2.0 的通用语言。任何兼容 MCP 的客户端都可以与任何兼容 MCP 的服务端通信。协议规定了一小组核心方法：

initialize —— 握手。客户端声明自己支持的协议版本和能力，服务端回应自己的。这个协商确保双方在进行任何工具调用之前就可用功能达成一致。
tools/list —— 发现调用。客户端问"你有哪些工具？"，服务端返回工具声明列表。每个声明包含名称、人类可读的描述，以及一个 inputSchema（JSON Schema 对象），精确告诉模型该工具接受哪些参数。这就是让模型在运行时无需预配置就能发现工具的机制。
tools/call —— 调用。客户端按名称选择工具，传入所需参数，服务端执行底层操作并返回结果。响应同时包含 structuredContent（机器可读的 JSON 数据）和 content（人类可读的文本），让模型既能程序化解析数据，也能用自然语言引用。

传输层是 Streamable HTTP，这意味着服务端是一个标准的 HTTP 端点，接受带有 JSON-RPC 请求体的 POST 请求。这很重要，因为 MCP Server 可以在任何 HTTP 基础设施后面运行——负载均衡器、CDN、API 网关——无需特殊配置。不需要管理长连接 WebSocket，不需要自定义二进制协议，客户端也不需要 SDK。任何 HTTP 客户端都可以说 MCP。

为什么这对 IP 情报尤其重要？因为 IP 数据天生就是工具化的。模型不能像读网页一样"读"一个 IP 地址。查询 IP 需要查数据库、关联 ASN 注册信息、对照威胁情报源、测量网络特征——这些都是有明确输入输出的离散操作，正是工具设计的场景。MCP 给了模型一种标准方式来触达这些操作，而 IPIPAI 的 MCP Server 给了它们 11 个工具。

三层架构

IPIPAI 的 MCP Server 不是独立服务，而是三层架构的中间层，将面向 AI 的协议与面向数据的 API 分离。理解这种分离是理解系统设计的关键。

ChatGPT / Claude / Gemini / Cursor │ │ JSON-RPC 2.0 (tools/list, tools/call) ▼ MCP Server (POST https://ipipai.com/mcp) │ │ Internal HTTP ▼ REST API (/api/v2/*, /api/*) │ ▼ Database / MMDB / External APIs

让我们逐层分析。

第一层：AI 客户端

最上层是发起请求的 AI 大模型或 Agent——Claude、ChatGPT、Gemini、Cursor，或基于任何 MCP 兼容运行时构建的自定义 Agent。这一层只说 JSON-RPC 2.0，不知道 IPIPAI 的 REST API、数据库 schema 或内部数据源。它只知道 MCP Server 通过 tools/list 声明的 11 个工具。这种隔离是刻意的：AI 客户端与 IP 情报后端的实现细节完全解耦。如果 IPIPAI 更换数据库厂商或修改内部 API 路径，没有任何 AI 客户端需要更新。

第二层：MCP Server

中间层是 MCP Server 本身，暴露在 POST https://ipipai.com/mcp。它的工作是翻译。当一个 JSON-RPC tools/call 请求到达——比如 {"method":"tools/call","params":{"name":"lookup_ip","arguments":{"ip":"8.8.8.8"}}}——MCP Server 将工具名映射到内部 REST API 端点，构造对应的 HTTP 请求，发送给第三层，接收响应，然后用 JSON-RPC 响应格式包装，同时包含 structuredContent 和 content 字段。

协议的魔法就在这一层发生。它负责声明 11 个工具及其输入 schema，根据 schema 验证传入参数，将调用路由到正确的内部端点，并以对语言模型最有用的方式格式化响应。从客户端角度看，MCP Server 是无状态的——每个 JSON-RPC 请求都是独立的，这使得它在负载均衡器后面可以轻松横向扩展。

第三层：REST API 与数据层

最底层是 IPIPAI 现有的 REST API（/api/v2/* 和 /api/* 端点）以及背后的数据基础设施：IP 情报数据库、用于地理定位和 ASN 数据的 MaxMind DB（MMDB）文件，以及 OpenIPAPI 等外部 API。这一层做实际工作——查询数据库、解析 MMDB 文件、运行网络探测、聚合结果。REST API 与程序员通过 @ipipai/sdk 直接使用的是同一个，这意味着 MCP Server 和 SDK 是同一个后端的两个不同前端。对于同一个查询，它们返回的数据完全相同，只是说的协议不同。

为什么要把 MCP Server 和 REST API 分开？

因为受众不同。AI 大模型需要一个自描述的、以发现为导向的协议（MCP），在运行时暴露工具及其 schema。程序员需要一个可预测的、可缓存的、以文档为导向的 API（REST），端点稳定、响应是直接的 HTTP JSON。试图用单一协议同时服务两类受众会两边都妥协。三层架构让每一层都能为自己的消费者做优化，而不会泄漏关注点。

两种接入方式：MCP 给 AI，REST API 给程序员

关于这次发布，最常见的问题是："MCP Server 会取代 REST API 吗？"答案是明确的不会。IPIPAI 现在提供两条互补的接入路径，每条为不同的消费者设计。

维度	MCP Server（给 AI 大模型）	REST API（给程序员）
协议	JSON-RPC 2.0	HTTP GET / POST
端点	`POST https://ipipai.com/mcp`	`https://ipipai.com/api/v2/*`
传输	Streamable HTTP	标准 HTTP
发现方式	运行时通过 `tools/list`	静态文档 + `/api/v2/discovery`
是否需要 API Key	不需要	需要（部分端点）
消费者	Claude、ChatGPT、Gemini、Cursor、Agent	脚本、服务、SDK、后端
响应格式	`structuredContent` + `content`	纯 JSON

如果你在构建 AI Agent 并希望它具备 IP 情报能力，你只需要把它指向 MCP Server。Agent 自行发现工具，在对话中按需调用。你不需要写任何集成代码——只需在 Agent 运行时（Claude Desktop、Cursor 设置或自定义 Agent 框架）中配置 MCP 端点。

如果你在构建后端服务、脚本或仪表盘，你直接使用 REST API 或通过 @ipipai/sdk 使用。你获得可预测的 HTTP 语义、标准的缓存头，以及对请求和响应处理的完全控制。REST API 不会消失——它是 MCP Server 自身构建的基础。

面对任意 AI 大模型：三种调用 IPIPAI 工具的方式

你不需要注册账号、不需要 API Key、也不需要专有 SDK。因为 MCP Server 是一个普通 HTTP 端点，任何大语言模型运行时、Agent 框架，甚至一个 shell 脚本都能驱动它。根据你的模型运行时选一种即可：

方式 A —— 连接原生支持 MCP 的客户端（Claude、Cursor 等）

任何 MCP 客户端都能把 IPIPAI 注册为远程服务器，让模型在对话中自动发现并调用工具。

// claude_desktop_config.json 或你所用 MCP 客户端的服务器列表
{
  "mcpServers": {
    "ipipai": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/inspector@latest", "ipipai", "--url", "https://ipipai.com/mcp"],
      "transport": "stdio"
    }
  }
}

@modelcontextprotocol/inspector 是 Anthropic 官方的 MCP 调试与连接工具。用它包裹 https://ipipai.com/mcp，就可以在本地 Web 界面里测试每个工具，也是连接任意兼容 Agent 的可靠方式。如果你的客户端原生支持远程 Streamable HTTP 服务器，也可以直接把 URL 设为 https://ipipai.com/mcp，无需任何包装。

方式 B —— 任何脚本或 Agent 通过普通 HTTP 调用

因为传输层是 Streamable HTTP，你可以直接用一条 curl 自行发送 JSON-RPC。这对任何自定义 Agent、定时任务或由任意大语言模型执行的函数都适用。下面的示例一次完成发现 → 调用：

# 1) 列出全部 11 个工具
curl -sS -N https://ipipai.com/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

# 2) 对随机地址调用 lookup_ip
curl -sS -N https://ipipai.com/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"lookup_ip","arguments":{"ip":"8.8.8.8"}}}'

方式 C —— 在任意语言中用 fetch 发送流式 JSON

同样的两个 POST 在 Python、Node、Go 或任意 HTTP 技术栈里都成立。一个能运行代码的模型只需要一次 HTTP POST——不需要任何 MCP 库：

import requests

resp = requests.post("https://ipipai.com/mcp", json={
    "jsonrpc": "2.0", "id": 1, "method": "tools/call",
    "params": {"name": "lookup_ip", "arguments": {"ip": "8.8.8.8"}}
}, headers={"Accept": "application/json, text/event-stream"})
print(resp.json()["result"]["structuredContent"]["ipai_score"])  # 例如 96

这三种方式都指向同一个端点（POST /mcp），都不需要密钥，限速为宽松的 60 次/分钟。选择与你当前运行的模型或 Agent 匹配的那一种即可。

如何连接：三步 JSON-RPC 交互流程

连接 IPIPAI MCP Server 不需要 API Key，不需要注册。任何兼容 MCP 的客户端都可以通过向 POST https://ipipai.com/mcp 发送 JSON-RPC 2.0 请求来连接。交互始终遵循三个步骤：初始化、发现、调用。

第一步：initialize

第一个请求是握手。客户端声明自己想使用的协议版本和自身身份。服务端回应自己的协议版本、能力和服务端信息。这一步确保双方在进行任何工具调用之前说的是同一种语言。

// 请求
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {},
    "clientInfo": {
      "name": "my-agent",
      "version": "1.0"
    }
  }
}

// 响应
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": {
        "listChanged": false
      }
    },
    "serverInfo": {
      "name": "IPIPAI MCP Server",
      "version": "2.0.0"
    }
  }
}

protocolVersion 字段是 2025-06-18，即当前的 MCP 规范版本。capabilities.tools.listChanged 字段告诉客户端工具列表是静态的——在会话期间不会变化，因此客户端不需要重新获取 tools/list，除非重新连接。serverInfo 将服务端标识为"IPIPAI MCP Server"版本 2.0.0。

第二步：tools/list

初始化之后，客户端请求完整的工具目录。发现就在这里发生。服务端返回一个包含 11 个工具声明的数组，每个声明包含 name（名称）、description（描述，模型通过阅读它来理解工具做什么）和 inputSchema（JSON Schema 对象，定义必填和可选参数）。

// 请求
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {}
}

// 响应（节选——共 11 个工具）
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "lookup_ip",
        "description": "完整 IP 情报：地理定位、ISP、ASN、IP 类型、风险评估和 0-100 评分。",
        "inputSchema": {
          "type": "object",
          "properties": {
            "ip": {
              "type": "string",
              "description": "要查询的 IP 地址"
            }
          },
          "required": ["ip"]
        }
      },
      // ... 还有 10 个工具
    ]
  }
}

这是 MCP 区别于传统 API 的关键时刻。模型不需要人类告诉它有哪些工具或接受什么参数。它读取 tools/list 响应，理解 schema，现在就能自主调用任何工具。如果 IPIPAI 明天新增第 12 个工具，模型在下一次调用 tools/list 时会自动发现它——不需要改代码、不需要重新部署、不需要客户端更新文档。

第三步：tools/call

模型确定了要使用哪个工具后（基于用户问题和工具描述），它发送一个 tools/call 请求，携带工具名和参数。服务端执行底层操作，返回包含两部分的结果：structuredContent（模型可以程序化解析的 JSON 对象）和 content（模型可以在回复中引用的文本表示）。

// 请求
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "lookup_ip",
    "arguments": {
      "ip": "8.8.8.8"
    }
  }
}

// 响应（节选）
{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "structuredContent": {
      "ip": "8.8.8.8",
      "country": "United States",
      "asn": "AS15169 Google LLC",
      "type": "datacenter",
      "score": 96,
      "grade": "A+",
      "risk_level": "very_safe"
    },
    "content": [
      {
        "type": "text",
        "text": "8.8.8.8 — Google LLC (AS15169)，数据中心 IP，位于美国。IPIPAI 评分：96/100 (A+)。风险等级：非常安全。"
      }
    ]
  }
}

无需 API Key

MCP Server 最重要的设计决策之一是不需要 API Key。任何兼容 MCP 的客户端都可以连接并立即开始调用工具。这消除了 AI 工具集成中最大的摩擦点——获取、管理和安全存储凭证。MCP Server 被设计为一个公共设施，任何模型都可以开箱即用。

11 个 MCP 工具详解

IPIPAI MCP Server 暴露 11 个工具，每个覆盖网络情报的一个特定领域。它们共同为 AI 大模型提供了一套全面的工具包，可以回答关于 IP 地址、域名、网络路径和服务可用性的任何问题。下面是每个工具的名称、描述、参数和典型使用场景。

1. `lookup_ip`

一次调用返回完整的 IP 情报：地理定位（国家、城市、坐标）、ISP、ASN、IP 类型（住宅、数据中心等）、风险评估（代理、Tor、黑名单标记）以及 0-100 的综合 IPIPAI 评分和字母等级。这是旗舰工具，也是大多数模型在用户询问 IP 地址时首先会选用的。

参数: ip (字符串, 必填)

2. `check_ip_reputation`

执行聚焦的 IP 信誉检查，检测该 IP 是否是已知代理出口节点、Tor 中继节点，或被列入主流威胁情报黑名单。比 lookup_ip 更轻量、更快，适合模型只需要安全判定而不需要完整画像的场景。

参数: ip (字符串, 必填)

3. `check_service_access`

检查特定服务是否可以从给定 IP 访问。支持 12 个服务，包括 ChatGPT、Claude、Gemini、Copilot、Netflix、Disney+、YouTube、Spotify、TikTok、Google、GitHub 和 Twitter。当用户问"这个 IP 能访问 ChatGPT 吗？"或"这个代理能解锁 Netflix 吗？"时，模型会使用这个工具。

参数: ip (字符串, 必填), service (字符串, 必填)

4. `rate_ip_node`

为 VPS、代理和数据中心 IP 生成综合节点评级。返回 0-100 评分、A+ 到 D 的字母等级，以及五个维度（纯净度、AI 可用性、网络质量、稳定性、安全性）的五星评分。这是回答"这个代理节点好不好？"的工具。

参数: ip (字符串, 必填)

5. `lookup_ip_location`

由 OpenIPAPI 驱动的快速地理定位查询。返回国家、地区、城市、经纬度、时区、ISP 和 ASN。比 lookup_ip 更轻量，适合模型只需要地理位置数据而不需要风险评分或服务检测的场景。

参数: ip (字符串, 必填)

6. `resolve_dns`

解析域名的 DNS 记录。返回 A、AAAA、CNAME、MX、TXT 等记录类型。当用户问"example.com 解析到什么 IP？"或模型需要先解析域名再用 lookup_ip 查询结果 IP 时使用。

参数: domain (字符串, 必填)

7. `ping_host`

向目标主机发送 ICMP ping 包，报告延迟、丢包率和可达性。模型用这个工具回答"这台服务器在线吗？"或"到这个 IP 的延迟是多少？"count 参数控制发送多少个包。

参数: target (字符串, 必填), count (整数, 可选)

8. `trace_route`

对目标主机执行路由追踪，显示网络路径上每一跳的 IP 地址和延迟。模型用这个工具诊断路由问题、识别流量在哪里被阻断，或理解两点之间的网络拓扑。max_hops 参数限制追踪深度。

参数: target (字符串, 必填), max_hops (整数, 可选)

9. `lookup_domain_whois`

查询域名的 WHOIS 记录，返回注册信息，包括注册商、创建日期、到期日期、域名服务器和注册人联系数据（在可用时）。当用户问"这个域名是谁的？"或"这个域名什么时候到期？"时使用。

参数: query (字符串, 必填)

10. `lookup_mac_vendor`

通过 MAC 地址查询网络设备的制造商（厂商）。使用 IEEE OUI 注册表将 MAC 地址的前三个八位组映射到厂商名称。当用户问"这块网卡是谁生产的？"或"什么设备有这个 MAC？"时使用。

参数: mac (字符串, 必填)

11. `check_website_availability`

检查 IPIPAI 网站及其核心服务是否在线并正常响应。这个工具不需要参数——它是一个健康检查。模型在进行其他调用之前验证服务可用性，或当用户问"IPIPAI 现在在线吗？"时使用。

参数: 无

模型如何在工具之间选择？

当用户问"查一下 8.8.8.8"，模型从 tools/list 中读取工具描述，看到 lookup_ip 提供"完整 IP 情报"。这是最全面的工具，所以它调用那个。如果用户具体问"8.8.8.8 是代理吗？"，模型可能转而选择 check_ip_reputation，因为它的描述聚焦于代理和黑名单检测。工具描述被编写为机器可读的，让模型可以自主做出这些决策。

实际示例："查询 8.8.8.8"

让我们走一遍完整的端到端交互。假设用户正在和 Claude 对话，问："查询 8.8.8.8，告诉我关于它的信息。"以下是幕后发生的事情。

1. 模型决定调用哪个工具

Claude 已经初始化了 MCP 连接并获取了工具列表。它阅读 11 个工具描述，将用户请求匹配到 lookup_ip——其描述说它返回"完整 IP 情报：地理定位、ISP、ASN、IP 类型、风险评估和 0-100 评分"。模型从用户消息中提取 IP 地址"8.8.8.8"并构造工具调用。

2. JSON-RPC 请求

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "lookup_ip",
    "arguments": {
      "ip": "8.8.8.8"
    }
  }
}

3. MCP Server 处理请求

MCP Server 接收 tools/call 请求，验证 lookup_ip 是已知工具且 ip 是有效参数，然后将调用翻译为对 REST API /api/v2/analyze（或等效内部端点）的内部 HTTP 请求。REST API 查询 MMDB 地理定位数据库、ASN 注册表、威胁情报源和风险评分引擎，聚合结果，将 JSON 文档返回给 MCP Server。

4. JSON-RPC 响应

MCP Server 将 REST API 响应包装成 JSON-RPC 格式，同时生成 structuredContent（原始 JSON 数据）和 content（文本摘要）：

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "structuredContent": {
      "ip": "8.8.8.8",
      "type": "datacenter",
      "country": "United States",
      "country_code": "US",
      "isp": "Google LLC",
      "asn": "AS15169",
      "asn_org": "Google LLC",
      "score": 96,
      "grade": "A+",
      "risk": {
        "level": "very_safe",
        "score": 12,
        "proxy": false,
        "tor": false,
        "hosting": true
      },
      "native": true,
      "recommendation": "优秀 — 高度适合 AI 工作流"
    },
    "content": [
      {
        "type": "text",
        "text": "8.8.8.8 属于 Google LLC (AS15169)，是美国的数据中心 IP。IPIPAI 评分：96/100 (A+)。风险等级：非常安全。未检测到代理、Tor 或黑名单标记。优秀，适合 AI 工作流。"
      }
    ]
    }
  }
}

响应便捷链接 — 点击直达

官网链接 official https://ipipai.com ↗

检测报告 report_url https://ipipai.com/ip/8.8.8.8 ↗

5. 模型回复用户

Claude 阅读 structuredContent 和 content 字段，综合生成自然语言回答，回复用户：

"8.8.8.8 是 Google 的公共 DNS 解析器，属于 Google LLC（AS15169）。它是位于美国的数据中心 IP。IPIPAI 给它打了 96 分（满分 100，等级 A+），意味着非常安全，没有代理、Tor 或黑名单标记。非常适合 AI 工作流。"

整个流程——从用户提问到模型回复——在几秒内完成。用户看不到 JSON-RPC 消息，他们只是问一个问题就得到有数据支撑的回答。这就是 MCP 的承诺：模型透明地处理工具发现、选择和调用，用户无需离开对话就能获得实时 IP 情报。

OpenIPAPI 集成

11 个工具中的 lookup_ip_location 由 OpenIPAPI 驱动，这是一个开源的 IP 地理定位项目。IPIPAI 将 OpenIPAPI 作为第三方数据源集成，用于快速、准确的地理定位查询。

OpenIPAPI 端点简单且无需认证：

GET https://openipapi.cloudshield.club/api?ip={ip}

查询 1.1.1.1 返回：

{
  "ip": "1.1.1.1",
  "country": "Australia",
  "country_code": "AU",
  "region": "New South Wales",
  "city": "Sydney",
  "latitude": -33.8688,
  "longitude": 151.2093,
  "timezone": "Australia/Sydney",
  "isp": "Cloudflare, Inc",
  "asn": "AS13335",
  "org": "Cloudflare, Inc"
}

MCP Server 的 lookup_ip_location 工具封装了这个端点。当模型调用 lookup_ip_location 传入 IP 地址时，MCP Server 向 OpenIPAPI 发送内部 HTTP 请求，接收地理定位 JSON，并以 MCP structuredContent 格式返回。模型不需要直接知道 OpenIPAPI 的存在——它只需调用工具就能获得结构化的位置数据。

为什么要集成独立的地理定位源？因为 OpenIPAPI 在地理定位这个特定领域针对速度和准确性做了优化。IPIPAI 自己的 lookup_ip 工具提供更广泛的情报画像（风险评分、服务访问、网络质量），但当模型只需要"这个 IP 在哪里？"时，由 OpenIPAPI 支撑的更轻量的 lookup_ip_location 工具更快更聚焦。两个工具互补：纯地理定位用 lookup_ip_location，完整情报画像用 lookup_ip。

OpenIPAPI 项目是开源的，托管在 GitHub 上。其数据由社区维护，覆盖全球 IP 段。通过将它作为多个数据源之一进行集成，IPIPAI 确保地理定位数据经过交叉验证并保持最新，而不依赖单一供应商。

SDK 与 MCP Server：两条路径，同一个后端

随着 MCP Server 与 @ipipai/sdk 并行可用，有必要澄清两者的关系。它们不是竞争关系——而是同一个后端的两个不同前端，为两类不同的消费者设计。

SDK 做什么

@ipipai/sdk 是一个 JavaScript/TypeScript HTTP 客户端（MIT 许可证，可在 npm 和 GitHub 获取），封装了 REST API。程序员安装它，用 API Key 初始化客户端，然后调用 client.analyze('8.8.8.8') 等方法。SDK 处理请求构造、响应解析和类型安全。当你在写代码时——Node.js 服务、Python 脚本（通过直接 HTTP）、浏览器仪表盘——它是正确的工具。

MCP Server 做什么

MCP Server 是一个协议层，通过 JSON-RPC 2.0 暴露同一个底层 REST API。它不需要 SDK、API Key 或任何客户端代码。AI 大模型连接它，在运行时发现工具，自主调用。当你想让 AI 大模型使用 IP 情报而不写集成代码时，MCP Server 是正确的工具。

两者的关系

SDK 和 MCP Server 最终都调用 IPIPAI 后端上相同的 REST API 端点。当你通过 SDK 调用 client.analyze('8.8.8.8') 时，它向 /api/v2/analyze 发送 HTTP POST。当模型通过 MCP 调用 lookup_ip 时，MCP Server 将其翻译为对 /api/v2/analyze 的同一个 HTTP POST。返回的数据完全相同，只是协议和消费者不同。

	@ipipai/sdk	MCP Server
消费者	写代码的程序员	发现工具的 AI 大模型
协议	HTTP (REST)	JSON-RPC 2.0
发现方式	静态（文档 + TypeScript 类型）	运行时（tools/list）
API Key	需要	不需要
客户端代码	安装 SDK，编写调用	配置 MCP 端点，完成
后端	同一个 REST API /api/v2/*

你应该用哪个？

如果你在构建 AI Agent 并希望它具备 IP 情报能力，使用 MCP Server——在 Agent 运行时中将 https://ipipai.com/mcp 配置为 MCP 端点，模型会处理其余一切。如果你在写应用代码（后端服务、脚本、仪表盘），使用 @ipipai/sdk 或直接使用 REST API。很多团队会同时使用两者：应用代码用 SDK，AI Agent 用 MCP Server。

总结：会自己发现工具的工具

IPIPAI MCP Server 的发布，代表了 AI 大模型获取网络情报方式的根本转变。在 MCP 出现之前，将一个工具集成到 AI Agent 中是一个手动的、代码密集的过程：你读 API 文档、写函数封装、定义 JSON schema、注册到模型运行时，然后祈祷不要变化。每新增一个工具就要重复这个循环。每次 API 更新都有破坏集成的风险。

MCP 消除了这个循环。模型通过调用 tools/list 自行发现工具，读取描述和输入 schema，根据用户问题决定调用哪个工具，通过 tools/call 执行调用。不需要集成代码，不需要 API Key，不需要先读文档。工具是自描述的，协议是标准化的。

对 IPIPAI 来说，这意味着任何兼容 MCP 的 AI 客户端——Claude、ChatGPT、Gemini、Cursor 或自定义 Agent——现在连接到 https://ipipai.com/mcp 的那一刻就能使用全部 11 个 IP 情报工具。用户可以问"查询 8.8.8.8"、"这个 IP 是代理吗？"、"这个 IP 能访问 ChatGPT 吗？"、"追踪到 example.com 的路由"或"这个域名是谁的？"——模型会找到正确的工具，调用它，返回有数据支撑的回答。用户和开发者只需把模型指向 MCP 端点，除此之外不需要做任何事情。

三层架构——AI 客户端、MCP Server、REST API——确保这一能力建立在坚实的基础上。MCP Server 是一个薄翻译层，真正的工作发生在 REST API 和其背后的数据基础设施中。这意味着 MCP Server 继承了 IPIPAI 现有后端的所有数据质量、准确性和覆盖范围，同时增加了 AI 大模型所需的发现和调用协议。

随着 MCP 生态的发展，我们预计会有更多 AI 客户端和 Agent 框架原生支持该协议。IPIPAI 的 MCP Server 今天已经准备好了。连接你的模型，让它发现工具，赋予它看见网络世界的能力。

IPIPAI MCP Server 正式发布：AI 大模型现在可以直接调用 IP 情报工具

引言：从 REST API 到原生 MCP

什么是 MCP（Model Context Protocol）？

三层架构

第一层：AI 客户端

第二层：MCP Server

第三层：REST API 与数据层

两种接入方式：MCP 给 AI，REST API 给程序员

面对任意 AI 大模型：三种调用 IPIPAI 工具的方式

方式 A —— 连接原生支持 MCP 的客户端（Claude、Cursor 等）

方式 B —— 任何脚本或 Agent 通过普通 HTTP 调用

方式 C —— 在任意语言中用 fetch 发送流式 JSON

如何连接：三步 JSON-RPC 交互流程

第一步：initialize

第二步：tools/list

第三步：tools/call

11 个 MCP 工具详解

1. lookup_ip

2. check_ip_reputation

3. check_service_access

4. rate_ip_node

5. lookup_ip_location

6. resolve_dns

7. ping_host

8. trace_route

9. lookup_domain_whois

10. lookup_mac_vendor

11. check_website_availability

实际示例："查询 8.8.8.8"

1. 模型决定调用哪个工具

2. JSON-RPC 请求

3. MCP Server 处理请求

4. JSON-RPC 响应

5. 模型回复用户

OpenIPAPI 集成

SDK 与 MCP Server：两条路径，同一个后端

SDK 做什么

MCP Server 做什么

两者的关系

总结：会自己发现工具的工具

1. `lookup_ip`

2. `check_ip_reputation`

3. `check_service_access`

4. `rate_ip_node`

5. `lookup_ip_location`

6. `resolve_dns`

7. `ping_host`

8. `trace_route`

9. `lookup_domain_whois`

10. `lookup_mac_vendor`

11. `check_website_availability`