每次在 AI 工具的设置里看到「MCP server」，你真正面对的其实是一段小小的 HTTP 对话。剥掉营销外壳，MCP 就是一套 AI 应用和外部服务怎么说话的规则，而这些规则是用 JSON-RPC 2.0 写的。这份指南把这段对话逐行读一遍，用 IPIPAI 的 MCP 端点做例子。
核心就一个想法
MCP（Model Context Protocol，模型上下文协议）标准化了一件事：让 AI 模型能用上模型之外的工具和数据。在 MCP 之前，每个集成都得定制——一个应用一套插件形态，另一个应用又是另一套。有了 MCP，服务器暴露一份标准的「工具」清单，任何讲这个协议的客户端都能发现并调用它们。服务器才不管客户端是 Claude、Cursor，还是你凌晨两点写的脚本。
JSON-RPC 2.0，一段话讲完
JSON-RPC 2.0 是一种请求/响应协议，每条消息都是一个小 JSON 对象。请求有三个部分：jsonrpc: "2.0"、一个 method 名字、一个你自己选的 id。响应带着同样的 id 回来，所以你永远知道它在回答哪个请求。没有流、没有状态、没有繁文缛节。会读 JSON，就能用肉眼排查它。
握手：initialize
任何 MCP 客户端的第一件事是自我介绍。它发一条 initialize 请求：
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"capabilities": {},
"clientInfo": { "name": "my-client", "version": "1.0" }
}
}服务器回自己的名字、版本和支持的协议版本。两边对上之后，客户端发 notifications/initialized，会话就绪。这里没有任何花活——就是协议里的「你好，我支持这些，你呢？」
发现工具：tools/list
接下来客户端问，你到底有什么可用的：
{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }IPIPAI 的服务器会回一个工具定义数组，每个定义包含名字、描述，和一个描述它预期参数的 JSON Schema。比如 lookup_ip 要一个 ip 字符串和一个可选的 lang。同样这份清单，浏览器友好的版本在 /mcp-tools.json。客户端会把它渲染成 AI 模型看到的工具选项。
运行工具：tools/call
模型决定用某个工具时，客户端发一条 tools/call 请求：
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "lookup_ip",
"arguments": { "ip": "8.8.8.8", "lang": "en" }
}
}服务器执行查询，把结构化结果放在 content 数组里返回。客户端把内容交给模型，模型就能基于活数据推理。整出戏就这一下：一次 POST，结构化 JSON 进，结构化 JSON 出。
错误长得跟正常响应一样
有个事常让人意外：失败不是 HTTP 错误。失败的请求照样返回 HTTP 200，只是带一个包含 code 和 message 的 JSON-RPC error 对象。这是故意的——让错误处理在所有客户端里保持统一。排查时，读 body 里的 error 字段，别看 HTTP 状态码。
为什么值得学这个？
因为同样的三条消息——initialize、tools/list、tools/call——会出现在你以后接触的每一个 MCP 集成里。一旦你会读它们，「把我的 AI 工具接到 IPIPAI」就不再是配置谜题，而是一条五行的 curl 命令。如果你现在正要配一个，接入指南专门讲了 Claude、ChatGPT 和 Cursor，AI 模型怎么调用 IP 工具则展示对话的模型侧。
收尾
MCP 不是魔法，是结构：一套固定的握手、一份工具目录、一个调用/响应循环，全部用 JSON-RPC 2.0 表达。只要你能从客户端跟到 IPIPAI 的 /mcp 端点看一条请求，你就已经把协议理解到可以往上搭东西的程度了。工具本身列在 /mcp-tools.json，更多内容在 IPIPAI 文章页。