VS Code扩展如何为非Copilot代理暴露实例级MCP工具？

核心结论 #

目前vscode.lm.registerMcpServerDefinitionProvider接口确实是VS Code为Copilot生态专属设计的MCP服务发现机制，Claude Code、Cursor、Antigravity等其他IDE内AI代理暂未实现对该原生接口的支持，你的接口使用方式没有问题。

详细分析 #

1. 接口支持范围现状 #

• 该API属于VS Code Copilot集成套件的一部分，官方仅保证Copilot系列工具能识别通过此接口注册的MCP服务器，其他第三方AI代理并未接入这套发现逻辑。
• 非Copilot类代理目前仅支持通过项目级配置文件（如.mcp.json、.vscode/mcp.json）指定stdio模式的MCP服务地址，无法自动识别VS Code扩展内注册的MCP服务。

2. 现有选项的优劣对比 #

选项1：仅支持Copilot

• 优势：实现成本极低，完全复用VS Code原生机制，自动适配远程环境、Codespaces、Docker容器等场景，不存在多实例匹配问题，能完美依托VS Code Git API提供功能。
• 劣势：覆盖用户群体受限，无法服务使用其他AI代理的开发者。

选项2：通过.mcp.json支持多代理

• 子选项a：重写为独立stdio MCP应用
  • 问题：必须剥离对VS Code Git API的依赖，重新实现合并冲突上下文获取、文件操作等核心功能，工作量大，且丢失IDE原生上下文集成的优势（如实时获取当前工作区状态）。
• 子选项b：stdio转发至扩展主机
  • 核心难点：同一目录下多VS Code实例的路由匹配问题——stdio进程无法直接关联到特定VS Code实例，容易出现调用串流错误。
  • 折中思路：可通过工作区路径哈希、VS Code实例PID生成唯一套接字/命名管道，让扩展自动生成项目级.mcp.json并注入标识，但跨环境（如Docker、Codespaces）的路径兼容性问题较难处理，且需要用户配合完成配置。

3. 集成式发现的可行性 #

你期望的「扩展提供VS Code实例级接口，仅当前实例内的代理自动识别」的模式，目前只能等待Claude、Cursor等厂商实现对McpServerDefinitionProvider接口的支持，但暂无明确的落地时间表。你可以向相关厂商提交功能请求，推动适配进程。

额外建议 #

• 优先完成Copilot的支持，保证核心功能可用；同时在扩展文档中提供其他代理的手动配置指引，比如自动生成.mcp.json模板，提示用户替换转发地址。
• 持续关注VS Code官方对MCP接口的更新，未来可能会推出更通用的跨代理服务发现机制。

内容的提问来源于stack exchange，提问作者jozxyqk