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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content具体到本文场景APIM 暴露的 MCP Server 走的是Ocp-Apim-Subscription-Key请求头鉴权而 VS Code 里其它 AI 工具可能走另一套 Key。把 TaoToken 作为统一通道后你可以在它的控制台里集中管理这些凭证减少在多个配置文件之间来回改的麻烦。需要拿 Key 的话走这个入口API Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite如果你后面要长期跑编码类 Agent可以考虑 Coding Plan把编码场景的调用单独规划Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewriteAPI 基础地址是 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 ServerAPIM 做代理Expose an API as an MCP server后端是普通 REST APIAPIM 把它包装成 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.jsonVS 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用httpheaders里带上 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_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite5. 本篇常见错排查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 Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite如果你在跑 Claude Code 这类编码 AgentAnthropic 兼容接入的说明在这里ClaudeCodeAnthropichttps://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude_code_anthropicutm_campaignrewrite最后留一个实操建议每次改完 APIM 的 MCP Server 配置先在 VS Code 里重新加载 MCP Server再看 Agent 模式的工具列表有没有更新别直接发调用请求不然报错信息会混在一起不好定位。