1. 存量 API 变 MCP Server，卡在哪一步
Azure APIM 里已经跑着一堆 REST API，现在想让 VS Code 里的 AI Agent 直接把它们当 MCP 工具调用，这件事听起来顺理成章，实际动手会发现两个坎：一是 APIM 侧「Expose an API as an MCP server」的配置路径和「Expose an existing MCP server」不是一回事，二是创建完 MCP Server 后，VS Code 连上去经常报fetch failed或 SSE 流被 terminated。这篇接着上一篇的试验往下走，聚焦把 APIM 中已有的 API 包装成 MCP Server 的完整配置骨架，以及在 VS Code 里完成一次工具发现加调用的验证动作。
适合谁看：已经在用 Azure APIM 管 API、想在 VS Code 的 Copilot Chat Agent 模式或其它 MCP 客户端里直接调用这些 API 的开发者。前置条件是一个可用的 APIM 实例、至少一个已导入的 API（本文用 Echo API 的 GET 操作做实验）、VS Code 加支持 MCP 的客户端扩展。整个流程不需要改后端 API 代码，全部在 APIM 策略层和客户端配置层完成。
我试过把全部 Operations 一次性勾选进去，结果启动就报错，后面会讲这个坑怎么绕。先把 APIM 侧的配置路径理清楚。
2. TaoToken 作为统一 Key 与 API 通道的前置准备
在讲 APIM 配置之前，先说一个实际开发中绕不开的问题：VS Code 里往往不止一个 MCP Server，还有各种 AI 编码工具、对话工具，每个都要单独配 Key、单独管额度，切换起来很碎。TaoToken 在这里的角色是统一 Key 和 API 通道——你可以在一个地方管理访问凭证，让 AI 工具通过统一入口接入，不用在每个客户端里重复填不同的 Key。
官网入口：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=
具体到本文场景，APIM 暴露的 MCP Server 走的是Ocp-Apim-Subscription-Key请求头鉴权，而 VS Code 里其它 AI 工具可能走另一套 Key。把 TaoToken 作为统一通道后，你可以在它的控制台里集中管理这些凭证，减少在多个配置文件之间来回改的麻烦。需要拿 Key 的话走这个入口：
API Keys 管理：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite
接入文档：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite
如果你后面要长期跑编码类 Agent，可以考虑 Coding Plan，把编码场景的调用单独规划：
Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite
API 基础地址是 https://taotoken.net/api ，注意这个地址不带 UTM 参数，配置时直接用。
注意：TaoToken 在这里是统一接入通道，不是替代 APIM 的角色。APIM 负责 API 网关和 MCP Server 暴露，TaoToken 负责 AI 工具侧的 Key 与通道统一，两者是配合关系。
3. APIM 侧把已有 API 暴露为 MCP Server 的配置骨架
3.1 创建 MCP Server 的入口与选项
登录 Azure 门户，进入目标 APIM 实例。左侧菜单选 APIs，再选 MCP servers。这里有两个容易混的入口：
| 入口选项 | 适用场景 |
|---|---|
| Expose an existing MCP server | 后端本身已经是 MCP Server，APIM 做代理 |
| Expose an API as an MCP server | 后端是普通 REST API，APIM 把它包装成 MCP |
本文要的是第二个。选+ Create MCP server，然后选Expose an API as an MCP server。
3.2 Backend 选择与那个「隐藏错误」
在 Backend MCP server 区域，选择 APIM 里已有的 API，比如默认的 Echo API。关键点在 Operations 勾选：如果你勾选全部 Operations，创建过程可能表面成功，但后续调用会出问题。这就是 excerpt 里提到的「隐藏错误」。
实测下来，稳妥做法是只勾选一个 GET 操作用于验证。比如 Echo API 里的Retrieve Resource。等验证通了，再按需逐个加。
在 New MCP server 区域填名称和描述，例如mcp-echo-server。可选地把它加入一个 Product，这样客户端就能用该 Product 的订阅密钥访问。
3.3 创建后拿到的 MCP Server URL
创建完成后，页面会给出 MCP Server URL，形如：
https://<your-apim>.azure-api.cn/mcp-echo-server/mcp这个 URL 就是 VS Code 里要配的地址。注意路径结尾的/mcp，别漏。
3.4 诊断日志的 payload 设置（关键排障点）
如果 APIM 实例在全局范围（所有 API）通过 Application Insights 或 Azure Monitor 开了诊断日志，需要把「前端响应」的「要记录的有效负载字节数」设为 0。这个设置防止在所有 API 中意外记录响应体，是 MCP Server 正常工作的前提之一。
如果要选择性记录特定 API 的 payload，就在 API 范围单独配，做针对性控制。全局设 0、单 API 按需开，这个组合最稳。
4. VS Code 侧配置与一次完整的工具发现调用
4.1 在工作区配置 mcp.json
VS Code 里可以通过命令面板执行MCP: Add Server，也可以直接在工作区的.vscode/mcp.json里写配置。推荐后者，方便版本管理。配置骨架如下：
{ "servers": { "my-mcp-server-echo": { "url": "https://<your-apim>.azure-api.cn/mcp-echo-server/mcp", "type": "http", "headers": { "Ocp-Apim-Subscription-Key": "<your-subscription-key>" } } } }type用http，headers里带上 APIM 的订阅密钥。密钥从 APIM 的 Subscriptions 页面拿，或者从你加入的 Product 的订阅里拿。
4.2 启动时可能遇到的报错
配好后启动 MCP Server，日志里可能出现：
Error connecting to https://xxxx.azure-api.cn/mcp-echo-server/mcp for async notifications, will retry Error reading SSE stream: TypeError: terminated Connection state: Error Error sending message to https://xxxxx.azure-api.cn/mcp-echo-server/mcp: TypeError: fetch failed这个fetch failed加 SSE terminated 的组合，多数情况就是 3.4 里说的诊断日志 payload 设置没调，或者 Operations 勾了全部导致响应体过大被截断。先按 3.4 把全局 payload 设 0，再把 MCP Server 的 Tools 收敛到单个 GET 操作。
4.3 收敛 Tools 到单个操作
导航到 APIM 的 MCP 服务页面，选 Tools 页，只勾选Retrieve Resource这一个操作作为测试。保存后回到 VS Code，重新加载 MCP Server。
4.4 在 Copilot Chat Agent 模式里验证调用
在 VS Code 的 GitHub Copilot Chat 里切换到 Agent 模式，输入类似：
调用 apim echo mcp 服务的 get 接口，获取 test 资源观察 MCP 调用情况。如果配置正确，Agent 会先做工具发现，列出my-mcp-server-echo暴露的工具，然后发起调用，返回 Echo API 的响应。这一步成功，说明 APIM 到 VS Code 的整条链路通了。
如果你在验证模型行为本身，想单独测对话通道，可以用模型对话入口：
模型对话：https://taotoken.net/model-chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite
5. 本篇常见错排查
5.1 fetch failed 与 SSE terminated
最常见。排查顺序：先确认 APIM 全局诊断日志的前端响应 payload 字节数是否为 0；再确认 MCP Server 的 Tools 是否只勾了单个 GET；最后确认.vscode/mcp.json里的 URL 结尾/mcp没漏、订阅密钥没写错。
5.2 工具发现为空
Agent 模式里看不到任何工具，通常是 MCP Server 创建时 Operations 没勾对，或者 Tools 页面里没启用任何操作。回到 APIM 的 MCP 服务 Tools 页确认。
5.3 订阅密钥无效
Ocp-Apim-Subscription-Key报 401，检查这个密钥是否属于包含该 MCP Server 的 Product。如果创建时没加入 Product，用 APIM 的 master 或对应订阅密钥。
5.4 创建时勾全部 Operations 的隐藏错误
前面反复提到。表现是创建看似成功，调用时响应异常。解决就是别勾全部，逐个加。
5.5 客户端类型不匹配
type写成sse或其它值，连接行为会不对。APIM 暴露的 MCP Server 用http。
提示：排障时优先看 APIM 侧的诊断日志和 VS Code 的 MCP 输出面板，两边对照能快速定位是网关侧还是客户端侧的问题。
6. 把这条链路接进你的日常工具流
APIM 把存量 API 暴露成 MCP Server 之后，VS Code 里的 Agent 就能直接调用这些 API 作为工具。实际用起来，建议把 MCP Server 的 Tools 按业务域拆分，而不是一个 Server 塞所有操作，这样工具发现更清晰，排障也更容易。
客户端侧的 Key 和通道管理，如果工具多了会变碎，用 TaoToken 统一管起来会省事。接入相关的配置和文档从这里走：
API Keys：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite
接入文档：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite
控制台：https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite
如果你在跑 Claude Code 这类编码 Agent，Anthropic 兼容接入的说明在这里：
ClaudeCodeAnthropic：https://taotoken.net/claude-code-anthropic?utm_source=taotoken_aicg_blog_end&utm_content=claude_code_anthropic&utm_campaign=rewrite
最后留一个实操建议：每次改完 APIM 的 MCP Server 配置，先在 VS Code 里重新加载 MCP Server，再看 Agent 模式的工具列表有没有更新，别直接发调用请求，不然报错信息会混在一起不好定位。
