1. MCP 初始化到底在握手什么MCP 初始化过程说白了就是 Client 和 Server 第一次见面时互相“对暗号”的过程。Client 问一句“你支持哪个协议版本、你叫什么、你能干啥”Server 回一句“我是谁、我支持哪些能力、我这边注册了哪些 Tool”然后 Client 再补一刀tools/list把 Server 暴露的工具清单拉回来。这一套走完LLM 的上下文里就已经有了当前可调用工具的名单模型后面要不要调、调哪个全靠这份清单里的名称、描述和参数定义来判断。很多人第一次配 MCP 的时候卡点不在协议本身而在“我的 Key 到底该写在哪”。因为 MCP Server 本身不负责模型推理它只负责提供工具能力真正要调模型的那一端是 Client 或者 Client 背后的 Agent 运行时。所以如果你用的是统一 Key/API 通道比如 TaoToken配置的落点通常有两个一个是 Client 侧的模型接入配置一个是 Server 侧如果它自己也要回调模型时的配置。搞混这两个位置就会出现“工具列表拉到了但模型请求 401”的经典问题。这篇就按初始化流程拆开讲先看握手阶段发生了什么再讲 TaoToken 的 Key 和 API 地址该放进哪个配置文件最后给你可复制的settings.json和config.toml骨架以及初始化成功后的验证动作。适合正在接 MCP Client、写 MCP Server或者用 Claude Code、Coding Agent 这类工具链的开发者。2. 握手流程与 Tool 注册的时序2.1 initialize 请求与能力协商MCP 的通信基于 JSON-RPC 2.0初始化阶段的第一步就是 Client 发initialize。这个请求里会带上 Client 自己的协议版本、能力声明和客户端信息。Server 收到后返回它支持的协议版本、Server 信息以及能力列表比如是否支持tools、resources、prompts。用文字画一下这个时序Client Server | | |------ initialize ------------| | | |----- initialize result ------| | (protocolVersion, | | serverInfo, capabilities) | | | |------ notifications/initialized -| | | |------ tools/list ------------| | | |----- tools/list result ------| | [QueryWeather, SearchOrder, | | GetInventory, ...] |注意notifications/initialized这一步它是 Client 告诉 Server“我准备好了”之后才正式进入工具发现阶段。有些实现里如果漏发这个通知Server 可能会拒绝后续的tools/list请求表现为初始化“看起来成功但工具列表为空”。2.2 tools/list 返回了什么tools/list返回的是一个数组每个元素包含name、description和inputSchema。inputSchema是 JSON Schema 格式描述这个工具需要哪些参数、参数类型是什么、哪些是必填。LLM 就是靠这三样东西决定要不要调用、怎么填参数。这里有个容易忽略的点Tool 的description写得越清楚模型判断越准。如果你写“查询天气”模型可能不知道要不要传城市名如果你写“根据城市名查询当前天气参数 city 为城市中文名”模型基本不会传错。初始化阶段拉回来的这份描述直接决定了后续调用的准确率。2.3 模型请求发生在哪一端关键来了tools/list只是把工具清单交给 Client真正发起模型请求的是 Client 或 Agent 运行时。也就是说TaoToken 的 Key 和 API 地址主要配置在 Client 这一侧。Server 侧只有在一种情况下才需要配你的 MCP Server 内部自己也要调模型做二次处理比如一个“总结工具”内部调 LLM。绝大多数场景下Server 只管执行工具逻辑不碰模型。所以配置的优先级是先确保 Client 侧的模型通道通了再去管 Server 侧。顺序反了你会花大量时间在 Server 日志里找一个根本不存在的模型请求。3. TaoToken 统一 Key 的放置位置3.1 为什么用统一通道MCP 生态里 Client 可能同时连好几个 Server每个 Server 背后可能对应不同的模型供应商。如果每个都单独配 Key管理成本很高而且切换模型时要改多处。用 TaoToken 这类统一通道的好处是一个 Key、一个 API 地址Client 侧改一处所有走模型请求的链路都跟着生效。对于 MCP 这种“Client 集中发起模型调用”的架构统一通道的收益特别明显。TaoToken 的 API 地址是https://taotoken.net/apiKey 在控制台的 API Keys 页面生成。生成后建议先放到环境变量里再在配置文件里引用避免明文写死在仓库里。3.2 settings.json 里的放置骨架如果你用的是 Claude Code 或类似支持settings.json的 Client模型通道配置通常放在顶层或env字段下。下面是一个可复制的骨架把ANTHROPIC_BASE_URL指向 TaoToken 的 API 地址ANTHROPIC_AUTH_TOKEN引用环境变量{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: ${TAOTOKEN_API_KEY} }, mcpServers: { weather: { command: dotnet, args: [run, --project, ./WeatherMcpServer], env: { MCP_LOG_LEVEL: info } }, order: { command: node, args: [./order-server/index.js] } } }这里要区分两个env外层的env是给 Client 自己用的模型请求走这里mcpServers里每个 Server 的env是给那个 Server 进程用的只有 Server 内部要调模型时才需要在那里也放一份。我见过有人把 Key 只写在 Server 的env里结果 Client 发模型请求时找不到凭证一直报 401。3.3 config.toml 里的放置骨架如果你的 Client 用config.toml结构类似只是语法不同。下面这个骨架把模型通道和 MCP Server 分开写[model] base_url https://taotoken.net/api api_key ${TAOTOKEN_API_KEY} provider anthropic [mcp.servers.weather] command dotnet args [run, --project, ./WeatherMcpServer] [mcp.servers.weather.env] MCP_LOG_LEVEL info [mcp.servers.order] command node args [./order-server/index.js]${TAOTOKEN_API_KEY}这种写法是否被支持取决于你的 Client 实现。如果不支持变量展开就改成读取环境变量的方式或者用 Client 提供的 secret 管理功能。不要把 Key 直接提交到 Git这是底线。3.4 Server 侧什么时候也要配只有一种情况你的 MCP Server 内部要调模型。比如你写了一个GenerateReport工具它内部要调 LLM 生成报告。这时候 Server 进程也需要拿到 Key 和 API 地址。配置位置就在mcpServers里那个 Server 的env下env: { TAOTOKEN_API_KEY: ${TAOTOKEN_API_KEY}, TAOTOKEN_BASE_URL: https://taotoken.net/api }然后在 Server 代码里读这两个环境变量去初始化模型客户端。如果 Server 只是查数据库、调内部 API那就不用配配了也是多余。4. 验证初始化是否成功4.1 看 Client 日志里的握手记录初始化成功的第一信号是 Client 日志里出现initialize的请求和响应。不同 Client 日志位置不同Claude Code 一般在~/.claude/logs或启动时的控制台输出里。你要找的关键字是protocolVersion、serverInfo和capabilities。如果只看到initialize请求没有响应说明 Server 进程没起来或者启动就崩了。4.2 确认 tools/list 返回非空第二个检查动作是确认tools/list返回了工具。可以在 Client 里执行一个查看工具列表的命令或者直接看日志里tools/list的响应体。如果返回空数组常见原因有三个Server 没有正确注册 Tool、notifications/initialized没发、Server 的 Tool 扫描路径不对。以 .NET 的 MCP Server 为例如果你用了WithToolsFromAssembly()要确保 Tool 类打了[McpServerToolType]特性方法打了[McpServerTool]。漏了特性扫描不到tools/list就是空的。4.3 发一次真实模型请求验证通道工具列表有了不代表模型通道通了。第三步是发一次真实请求让模型基于工具列表做一次判断。比如在 Client 里输入“武汉今天天气怎么样”观察日志里是否出现模型请求、是否走到tools/call、Server 是否返回结果。如果模型请求返回 401 或 403说明 TaoToken 的 Key 或 API 地址配错了。检查ANTHROPIC_BASE_URL是不是https://taotoken.net/api注意结尾不要多加/v1之类的路径除非你的 Client 明确要求。Key 的话确认环境变量在当前 shell 会话里真的生效了可以用echo $TAOTOKEN_API_KEY看一眼。4.4 用 curl 直接测通道想排除 Client 配置的干扰可以直接用 curl 测一下 TaoToken 的通道是否可达curl -s -o /dev/null -w %{http_code} \ -X POST https://taotoken.net/api/v1/messages \ -H x-api-key: $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d {model:claude-3-5-sonnet-20241022,max_tokens:16,messages:[{role:user,content:hi}]}返回 200 说明通道和 Key 都没问题问题在 Client 配置返回 401 说明 Key 无效返回 404 说明路径不对。这个动作能帮你快速定位是通道问题还是 Client 问题。5. 初始化阶段常见错排查5.1 工具列表为空现象是tools/list返回[]。排查顺序先看 Server 日志有没有启动成功再看 Tool 注册代码有没有被执行最后看notifications/initialized有没有发。.NET 项目里如果WithToolsFromAssembly()没生效可以换成手动注册WithToolsWeatherTool()试试能排除程序集扫描的问题。5.2 模型请求 401现象是工具列表正常但一发消息就报鉴权失败。九成是 Key 没配到 Client 侧或者环境变量没展开。检查settings.json里外层env的ANTHROPIC_AUTH_TOKEN是否指向了正确的环境变量名以及这个环境变量在启动 Client 的终端里是否存在。用env | grep TAOTOKEN确认一下。5.3 协议版本不匹配现象是initialize返回错误提示协议版本不支持。MCP 协议还在演进Client 和 Server 用的 SDK 版本差太多时会出现。解决办法是升级其中一端的 SDK或者看 Server 返回的protocolVersion是否在 Client 支持列表里。日志里一般会打印双方版本号对比一下就知道。5.4 Server 进程启动即退出现象是 Client 日志里initialize请求发出去后没有响应Server 进程已经没了。常见原因是 Server 启动命令写错、依赖没装、或者 Server 在启动时读环境变量失败直接抛异常。把 Server 的启动命令单独在终端跑一遍看报错信息比在 Client 日志里猜快得多。5.5 工具调用参数校验失败现象是模型决定调用工具了但 Server 返回参数错误。这通常是inputSchema和实际方法签名不一致。比如 Schema 里写city是 string方法参数却是CityName序列化时对不上。检查 Tool 方法的参数名和 Schema 里的属性名是否完全一致大小写也要对。6. 配置落地与后续接入把上面几步串起来你的初始化链路应该是Client 启动时读settings.json或config.toml从环境变量拿到 TaoToken 的 Key 和 API 地址连接 MCP Server 后完成initialize握手拉回tools/list模型请求走 TaoToken 通道工具调用走 MCP Server。两条链路各管各的不要混。如果你还没生成 Key可以去控制台的 API Keys 页面创建一个然后按接入文档把地址和 Key 填进对应配置文件。想先验证模型通道是否正常可以用模型对话页面发一条消息试试。长期跑编码类 Agent 的话Coding Plan 那条链路更适合持续调用配置方式类似只是计费和额度模型不同。配置这件事最怕的就是“看起来都配了但就是不生效”。我的习惯是每改一处配置就用 curl 或日志验证一次确认这一层通了再动下一层。初始化阶段的问题八成都能通过“先测通道、再看握手、最后查工具注册”这个顺序定位到。