企业官网建设流程全解析

读 MCP 协议文档时通常绕不开三件事：请求、响应、通知，以及 Host、Client、Server 的分工。问题是文档不会告诉你这些消息在 Claude Code 里对应哪一段日志。这篇文章用 Claude Code 配 TaoToken 的方式把这些抽象概念落到真实配置里；TaoToken 官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 可以创建 API Key，拿到 Key 之后再往下看，三种 JsonRPC 格式就不再是纸面上的 JSON 示例，而是你在调试日志里亲眼能看到的东西。

1. 先分清 MCP 协议层与模型 API 层：为什么先配 TaoToken 的 Key

1.1 MCP 解决的是外设接入，不是模型连接

原文把 MCP 比作给电脑挂外设：大模型是“大脑”，文件读取器、数据库连接器这类能力是“手脚”。这个比喻容易让人忽略一个前提——大脑本身得先醒来。在 Claude Code 里，“大脑”对应你配置的模型通道，MCP Server 是后来接上去的工具集。不少人的顺序是反的：先挂 MCP Server，再发现 Claude Code 连模型都调不通，于是所有排查都落在 MCP 配置上，白白消耗时间。

TaoToken 在这里解决的就是模型通道这一环。Claude Code 把 Anthropic 兼容的模型请求发到 TaoToken 的接口，TaoToken 再路由到你选择的模型。对 Claude Code 来说，TaoToken 看起来就是一个标准 API 服务，它内部的 MCP Client 行为不会受任何影响。也就是说，MCP 的 JsonRPC 消息仍然由 Claude Code 自己封装和解析，TaoToken 只负责让“大脑”先正常工作。

1.2 模型通道不通时先看现象再定层

把 MCP Server 挂好后最典型的现象是：Claude Code 启动成功，但让它调用工具时迟迟不执行，或者直接说“我没有可用工具”。此时用claude mcp list看，Server 又确实是 connected 状态。问题不在 MCP，而在模型没接管对话：Host 收不到模型返回的工具调用意图，自然无法触发 Client 发送tools/call。

这种情况先查模型层，不要动 MCP。确认 settings.json 里的环境变量指向 TaoToken，并让 Claude Code 完成一次普通对话。模型 ID 以 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 的模型广场为准，不要凭记忆填型号；同一个模型名在不同通道下的可用状态可能不同。这里要特别区分两个地址：官网落地页https://taotoken.net/?utm_source=taotoken_aicg_blog_end是注册、创建 Key、看用量的地方；填进配置文件的 Base URL 是https://taotoken.net/api，末尾不要加/v1。混用这两个地址，后面所有调试都会变得奇怪。

2. Host、Client、Server 在 Claude Code 里各是谁

2.1 把原文角色表翻译成进程

原文那张角色表里：MCP Host 是大模型所在的应用，MCP Client 是嵌入 Host 的翻译官，MCP Server 是外部能力提供者。放到 Claude Code 配 TaoToken 的环境里，可以一一对应：

• Host 是claude主进程，负责展示对话框、读取配置文件、决定何时调用工具。
• Client 是 Claude Code 内置的 MCP Client，负责把模型的工具调用意图翻译成 MCP 协议指令，发给 Server，再接收结果。
• Server 是执行claude mcp add时指定的外部命令或服务，不关心模型是谁，只关心自己能不能执行任务并返回结果。

TaoToken 只出现在第一层。它把 Claude Code 的 HTTP 模型请求接入对应模型，与 MCP Server 之间没有直接通信。一整条链路是：模型（经 TaoToken 通道）决定要干什么，Claude Code 的 Client 把决定翻译成 JsonRPC 请求，MCP Server 执行并响应。

2.2 一次完整工具调用的时序

让 Claude Code 列一下某个目录里的文件，后台实际发生的是：

1. Claude Code 把用户问题连同工具清单发给模型，走的是 TaoToken 接口。模型返回一段包含工具调用意图的响应。
2. Client 给对应 MCP Server 发送initialize请求，Server 返回协议版本和能力。
3. Client 发送tools/list，拿到 Server 支持的工具清单。
4. 模型基于工具清单决定具体调用哪个工具。
5. Client 发送tools/call，参数里是工具名和输入参数。
6. Server 执行完返回result，Host 把结果作为上下文再交给模型，模型生成最终回答。

第 2 到 6 步就是 MCP 的请求和响应。开了 debug 模式后，你会在日志里看到成对的id数字，那就是请求和响应的对应标记。

2.3 模型 API 与 MCP Server 的边界

有一种配置思路容易入坑：试图把 MCP Server 的地址填给 TaoToken。不需要。MCP Server 的地址只填给 Claude Code；TaoToken 只需要ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN和ANTHROPIC_MODEL。换句话说，Claude Code 一边连着 TaoToken 的模型接口，一边连着本地或远程的 MCP Server，两边协议不同，互不干扰。TaoToken 提供的是统一 API 兼容通道，MCP 的消息封装由 Claude Code 完成；两者各自独立，但缺了任何一环，工具调用都走不完。

3. JsonRPC 的请求、响应、通知在 Claude Code 里的真实长相

3.1 请求消息：id、method、params

原文里的请求格式是jsonrpc固定为2.0，id是唯一标识，method是方法名，params是参数。这个格式在 Claude Code 的日志里能看到大量实例。比如initialize请求：

{ "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2024-11-05", "capabilities": { "tools": {} }, "clientInfo": { "name": "claude-code", "version": "1.x" } } }

真正让 Server 干活的请求是tools/call：

{ "jsonrpc": "2.0", "id": 7, "method": "tools/call", "params": { "name": "read_file", "arguments": { "path": "/tmp/example.txt" } } }

注意id是自增的。Client 和 Server 靠它把请求和响应关联起来，所以你会在日志里看到连续递增的数字。

3.2 响应消息：result 与 error 的分支

响应必须带与请求相同的id。成功时是result，失败时是error，两者不会同时出现。一个成功的tools/call响应：

{ "jsonrpc": "2.0", "id": 7, "result": { "content": [ { "type": "text", "text": "这是 /tmp/example.txt 的内容" } ] } }

失败时返回 error 对象：code是数字，message是描述，data可带额外信息。比如工具参数不合法，code可能是-32602，message是 invalid params。Claude Code 不一定会把这类 error 弹到界面上，它有时只是 debug 日志里的一行。所以遇到“工具没反应”别急着怀疑网络，先翻日志。

3.3 通知消息：没有 id 的单向信号

通知是三种格式里最容易被忽略的：只有method和params，没有id，接收方也不需要回复。MCP 里最常见的通知是初始化完成后的notifications/initialized，以及长耗时任务里的进度通知：

{ "jsonrpc": "2.0", "method": "notifications/progress", "params": { "progressToken": "task-123", "progress": 0.5 } }

在 Claude Code 的 debug 日志里，通知通常单独出现，前后没有配对记录。第一次看日志时，别把它当成丢消息，这是协议的正常设计。

3.4 在日志里验证三种格式

想亲眼看到这三种格式，最省事的办法是用claude --debug启动会话，然后让 Claude Code 调用某个 MCP Server 提供的真实工具。日志会按时间顺序打印 Client 与 Server 之间的字符流，搜索jsonrpc就能定位到请求、响应和通知。注意一点：如果你在日志里看到大量 HTTP 401，那是模型通道的问题，和 MCP 无关，直接跳到第 4 章的排障清单处理。

4. 从 Key 到验证：Claude Code 接一个 filesystem MCP Server

4.1 准备三样材料

现在进入实战。准备三样东西。

第一，API Key。打开 TaoToken 注册并创建新 Key，把拿到的 Key 填入配置文件的ANTHROPIC_AUTH_TOKEN，本文统一用YOUR_API_KEY占位。注意占位符的意思是让你用自己的 Key 替换它，不是原样保留。

第二，Base URL。填https://taotoken.net/api，它不进浏览器，只进配置文件，末尾不加/v1。

第三，模型 ID。翻 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 的模型广场，复制当前可用的模型 ID，填进ANTHROPIC_MODEL。每个历史阶段模型列表会有变化，以你打开时看到的状态为准。

4.2 settings.json 与 mcp add 命令

Claude Code 支持把配置写到~/.claude/settings.json。编辑这个文件：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY", "ANTHROPIC_MODEL": "你的模型ID" } }

ANTHROPIC_MODEL里的内容不要照抄“你的模型ID”，去模型广场复制实际 ID，否则 Claude Code 会在启动时报模型不存在。

接下来添加 MCP Server。这里用 filesystem server 做实验，它能列目录、读文件，适合观察 JsonRPC 消息。在项目目录执行：

claude mcp add filesystem --transport stdio -- npx -y @modelcontextprotocol/server-filesystem /tmp

执行后用claude mcp list确认 Server 状态。如果显示 connected，说明 Client 已经能把这个 Server 拉起来。

4.3 启动 claude --debug 验证遍历

配置完成后，运行：

claude --debug

进入会话后输入：“列出 /tmp 目录下的文件。”日志里会依次出现三类内容：

• initialize请求和响应：验证请求消息与响应消息的id对应关系。
• tools/list请求和响应：响应里是文件系统相关的工具集合，说明 Client 成功拿到了能力清单。
• tools/call请求和响应：请求参数里有工具名和目录路径，响应里有文本结果。

进度通知一般在 Server 处理慢时出现。你可以让 Claude Code 读取一个深层目录或做一次耗时遍历，看到notifications/progress的概率会增加。验证重点不是只看这几个 JSON，而是确认整个链路闭环：模型请求确实经由 TaoToken 完成，工具返回结果也回到了模型上下文里，最后 Claude 给出了自然语言回答。

4.4 常见报错与分层排障

按这一套配置，最容易遇到这些问题：

• 401 Unauthorized：ANTHROPIC_AUTH_TOKEN还是YOUR_API_KEY没有替换成真实 Key，或者 Key 在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 创建后没复制完整。
• 404 Not Found：Base URL 写成了https://taotoken.net/api/v1或https://taotoken.net。正确接口地址是https://taotoken.net/api，网站地址只用来处理账号和用量。
• 启动时提示模型不存在：ANTHROPIC_MODEL的内容和模型广场对不上，或者带了日期后缀等多余字符。
• claude mcp list显示 pending 或 error：先确认npx命令能否在终端单独运行，以及目录参数是否存在。
• 对话里 Claude 说没有可用工具：模型层大概率没调通。工具连接状态正常不代表模型会调用它，先做一次普通对话确认模型能返回回复。

排障时始终记住分层原则：MCP 相关消息在 Claude Code 与 Server 之间，模型相关消息在 Claude Code 与 TaoToken 之间。报错出现在哪一段，就查哪一段的配置，不要一上来就改配置文件里的所有字段。

5. 配通之后回官网看用量，再回头读协议

5.1 在官网确认本次调用记录

看到tools/call的成功响应后，MCP 这条线的三种 JsonRPC 消息就都验证过了。建议打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 看一眼这次会话的调用记录，确认刚才的请求确实发生了。这一步能让你对 API 消耗有体感，也顺便核对模型 ID 实际运行的用量，比之后出了问题再回查要轻松。

5.2 再用原文的三种消息格式做一次复盘

拿着你刚在 debug 日志里看到的真实消息，重新对照协议原文：请求消息里id是谁生成的，响应消息里的id是哪个，通知消息为什么不需要回复。你会发现 Host、Client、Server 不再抽象——Host 就是claude进程，Client 是它内置的翻译官，Server 是npx拉起来的工具集。以后再给 Claude Code 加数据库 MCP Server 或远程 HTTP MCP，你至少知道该去哪个日志找哪一段，而不是对着未知错误码从零开始猜。