--- title: "在 VS Code Copilot Chat 中配置 MCP" wiki: mcp category: "客户端集成" slug: vscode-setup url: https://learnagent.wiki/mcp/cards/vscode-setup tags: ["MCP", "VS Code", "GitHub Copilot", "Agent Mode", "配置", "第三方客户端"] last_updated: 2026-04-11 reading_time: 12 --- > 如果你平时主要在 IDE 里写代码，那 VS Code 的 MCP 支持很适合你。它的核心价值不是“又多了一个能配 MCP 的客户端”，而是：**让 GitHub Copilot 的 Agent 模式直接长出外部工具手脚**。你不用离开编辑器，就能让 Copilot 去读 GitHub、跑浏览器、查数据库、打开内部文档，甚至把 MCP 提供的资源和提示词模板直接塞进当前对话。 # 在 VS Code Copilot Chat 中配置 MCP ## 基础概念 如果你平时主要在 IDE 里写代码，那 VS Code 的 MCP 支持很适合你。它的核心价值不是“又多了一个能配 MCP 的客户端”，而是：**让 GitHub Copilot 的 Agent 模式直接长出外部工具手脚**。你不用离开编辑器，就能让 Copilot 去读 GitHub、跑浏览器、查数据库、打开内部文档，甚至把 MCP 提供的资源和提示词模板直接塞进当前对话。 按 VS Code 官方发布时间线来看，**MCP server 支持从 2025 年 3 月发布的 VS Code 1.99 开始提供，到 2025 年 6 月发布的 VS Code 1.102 转为 General Availability（GA）**。也就是说，这已经不是一个只能“试试看”的实验角落，而是 VS Code 官方正式支持的集成能力。 和 Claude Desktop 那种“桌面聊天 + 本地工具”模式不一样，VS Code 的优势在于它把 MCP 和 IDE 工作流绑得很紧： - 工具可以直接被 Copilot Agent 选中并调用 - 资源可以通过 `Add Context > MCP Resources` 加进上下文 - Prompt 模板会以斜杠命令的形式出现 - 配置既可以做成个人级，也可以做成工作区级，适合团队共享 ### 核心要素 | 要素 | 作用 | |------|------| | **运行前提** | 需要 VS Code、GitHub Copilot 和 Agent 模式；企业环境下管理员还可能通过策略控制 `chat.agent.enabled` 与 `chat.mcp.access` | | **配置位置** | 可以配在当前仓库的 `.vscode/mcp.json`、用户配置文件里的 `mcp.json`、远程窗口的用户配置，或 `devcontainer.json` | | **传输方式** | 本地常用 `stdio`，远程常用 `http`；`sse` 仍兼容旧服务，但官方更推荐用 Streamable HTTP | | **使用入口** | 聊天窗口的工具选择器、`#` 显式点名工具、`Add Context` 里的 MCP Resources、Prompt 斜杠命令 | | **安全机制** | 第一次启用工作区里的 Server 需要信任确认；Server 启停、输出日志、重置信任都能在 VS Code 里直接管理 | ### 从配置到调用的完整流程 ```mermaid graph LR A["选择配置位置
workspace / user / remote"] --> B["写入 MCP 配置
mcp.json / 扩展 / CLI"] B --> C["VS Code 发现 Server"] C --> D["首次启用并确认信任"] D --> E["Copilot Chat 读取工具 / 资源 / Prompts"] E --> F["Agent 自动调用
或用 # 显式指定"] ``` ### 到底该配在哪一层 ```mermaid graph TD Start["我要把 MCP Server 配到 VS Code"] --> Q1{"只在当前仓库用吗？"} Q1 -->|"是，而且想跟团队共享"| W["配到 .vscode/mcp.json"] Q1 -->|"不是，多个项目都想复用"| Q2{"Server 跑在远程环境里吗？"} Q2 -->|"不是，本机通用"| U["配到 User Profile 的 mcp.json"] Q2 -->|"是，走 SSH / Dev Container / WSL"| R["配到远程窗口的用户配置
或 devcontainer.json"] ``` ## 基础用法 ### 第一步：确认前置条件 最少要满足这几件事： 1. VS Code 版本不低于 **1.99** 2. 已登录并可使用 **GitHub Copilot** 3. 聊天窗口可切到 **Agent 模式** 4. 如果是企业托管账号，管理员没有禁用 `chat.agent.enabled` 或 `chat.mcp.access` 可以先在终端确认 VS Code 版本： ```bash code --version ``` ### 第二步：在工作区写一个最小配置 最常见的做法，是在当前项目根目录创建 `.vscode/mcp.json`。下面这个示例同时接了一个远程 GitHub MCP Server 和一个本地 Playwright Server： ```json { "servers": { "github": { "type": "http", "url": "https://api.githubcopilot.com/mcp" }, "playwright": { "command": "npx", "args": [ "-y", "@microsoft/mcp-server-playwright" ] } } } ``` 这段配置翻译成人话就是： - `github` 走 `http`，适合那种已经托管好的远程 MCP 服务 - `playwright` 走本地命令启动，VS Code 会帮你执行 `npx -y @microsoft/mcp-server-playwright` - `servers` 下面每一项就是一个独立的 MCP Server，Copilot 会把它们暴露出来的能力汇总给 Agent 如果你不想手写 JSON，也可以直接用 VS Code CLI 添加： ```bash code --add-mcp '{"name":"playwright","command":"npx","args":["-y","@microsoft/mcp-server-playwright"]}' ``` ### 第三步：启动并确认信任 配置写完后，VS Code 会发现这些 Server。你可以通过下面几种方式管理它们： - 命令面板里运行 `MCP: List Servers` - 打开 `mcp.json`，直接用文件顶部的操作入口启停 - 在 Extensions 视图里看 `MCP` 分类 如果这是工作区级 Server，**第一次启用时通常会弹出信任确认**。这里的意思不是“这个协议危不危险”，而是“你是否允许这个仓库里的配置在本机启动外部程序或访问外部服务”。 > 一个细节要记住：如果 Server 是你直接在 `mcp.json` 里手动写的，VS Code 不一定再额外弹一次 trust 提示，所以配置来源一定要自己把关。 ### 第四步：在聊天里实际调用 一旦 Server 正常启动，Copilot Chat 就能消费它暴露出的能力： - **Tools**：直接给 Agent 调用 - **Resources**：通过 `Add Context > MCP Resources` 加进对话上下文 - **Prompts**：作为斜杠命令显示在聊天里 最小体验方式： ```text 你：审查一下我当前仓库最近打开的 PR，并用浏览器打开登录页做一次冒烟测试。 Copilot：先调用 GitHub MCP 工具读取 PR，再调用 Playwright MCP 工具打开页面并执行检查。 ``` 如果你不想让 Agent 自己挑工具，也可以在输入框里键入 `#`，明确点名某个 MCP Tool。 ### 第五步：共享给团队 VS Code 这套做法最大的实际价值，是**能把 MCP 配置当项目配置一起带走**。常见做法有两种： - 把 `.vscode/mcp.json` 提交进仓库，让团队成员拿到相同的 Server 列表 - 如果你的项目本来就用 Dev Container，把 MCP 配置写进 `devcontainer.json`，这样进入容器就自动具备同一套工具环境 ## 同类工具对比 “在 VS Code 里配 MCP”不是唯一方案。你可以把它和另外两条常见路线放在一起看： | 维度 | VS Code Copilot Chat + MCP | VS Code 原生 AI 扩展 / Language Model API | Claude Code + MCP | |------|----------------------------|--------------------------------------------|-------------------| | 上手成本 | **低**，写配置即可 | **高**，需要自己开发扩展 | **低**，主要靠 CLI 命令 | | 要不要写代码 | 不需要 | 需要 | 不需要 | | 最适合场景 | 在 IDE 内改代码、调试、审 PR、联动编辑器上下文 | 做深度 VS Code 集成、发布到 Marketplace、控制自定义 UI/命令 | 终端开发流、Git/命令/仓库自动化 | | 配置共享 | 强，`.vscode/mcp.json` / `devcontainer.json` | 靠扩展发布与版本管理 | 强，`.mcp.json` 或 project scope | | 工作流重心 | 编辑器内 | 扩展开发 | 终端内 | 核心区别： - **VS Code Copilot Chat + MCP**：最适合“我想马上让 IDE 里的 Agent 接上外部工具”，几乎零代码。 - **VS Code 原生 AI 扩展 / Language Model API**：适合你需要更深的 VS Code API 集成，比如命令面板、面板 UI、扩展发布。 - **Claude Code + MCP**：适合你的主战场是终端，不是编辑器窗口。 ## 常见误区 | 误区 | 准确理解 | |------|----------| | 以为装了 GitHub Copilot 就天然能用 MCP | 还需要 Agent 模式可用，而且企业环境下管理员可能通过策略禁掉 MCP 访问 | | 以为 VS Code 只能连本地 Node.js 写的 MCP Server | 不是。VS Code 同时支持本地命令启动和远程 HTTP Server；`sse` 也还能兼容旧服务 | | 以为 Tools、Resources、Prompts 在聊天里表现完全一样 | 不一样。Tools 给 Agent 调，Resources 需要你加到上下文里，Prompts 则会变成斜杠命令 | | 以为把 `.vscode/mcp.json` 提交到 Git，所有同事就会立刻自动启用 | 不是。工作区共享的是配置，不是“替你批准执行”的动作；首次启用通常仍要个人确认 | | 以为敏感 Token 直接写进 `mcp.json` 就行 | 不推荐。共享配置时更应该用环境变量、输入变量或安全的凭证注入方式 | | 以为 Server 起不来就是 VS Code 的锅 | 很多时候是启动命令、运行时依赖、环境变量或日志输出没看；先去 `MCP: List Servers` 和输出面板查状态 | ## 优劣势分析 | 优势 | 劣势 | |------|------| | **IDE 内闭环最强**：编辑、对话、上下文、工具调用都在同一个窗口里完成 | **前置条件比桌面聊天更重**：要有 VS Code、Copilot 和 Agent 模式，不是装上就人人可用 | | **团队共享自然**：`.vscode/mcp.json` 和 `devcontainer.json` 很适合项目沉淀 | **配置层级有点多**：workspace、user、remote、devcontainer 几层一多，新手容易搞混 | | **不只支持 Tools**：Resources、Prompts、Apps 在 VS Code 里也都有对应入口 | **调试仍然要看日志**：Server 启动失败时，本质上还是在排查外部进程或远程服务 | | **安全感知更明确**：启用、停用、重置信任、查看输出都在 IDE 内可见 | **共享配置不等于共享凭证**：团队要统一工具还得另外设计环境变量和权限方案 | | **适合远程开发**：SSH、WSL、Dev Container 都能放进配置体系里 | **某些生态还在演进**：不同 Server 对 Resources、Prompts、Apps 的支持度不完全一致 | ## 思考题
初级：什么时候该把 MCP Server 放进 `.vscode/mcp.json`，什么时候该放到用户级 `mcp.json`？ **参考答案：** 判断标准就一个：**这个 Server 是“项目资产”还是“个人习惯”**。 如果它和当前仓库强相关，比如前端仓库统一接 Playwright、后端仓库统一接只读数据库、全团队都要审 GitHub PR，那就更适合放进 `.vscode/mcp.json`。这样仓库一 clone 下来，大家都能看到同一套 MCP 配置，团队协作成本最低。 如果它是你个人长期复用的工具，比如你自己的知识库、私人 Notion、个人 Sentry、只在自己电脑可用的本地服务，那更适合放到用户级 `mcp.json`。这样你换项目也能继续用，不会把个人偏好带进团队仓库。
中级：为什么 VS Code 要把“共享配置”和“是否启用/是否信任”分成两步，而不是看到配置就直接跑？ **参考答案：** 因为 MCP 配置的本质，不只是“描述信息”，而是**可能直接启动本地进程、访问外部服务、读写敏感资源的执行入口**。 如果仓库里只要出现 `.vscode/mcp.json` 就自动执行，那你 `git clone` 一个陌生项目时，IDE 可能立刻在本机启动一堆你没审过的命令。这显然不安全。 所以 VS Code 把这件事拆成两层： 1. **配置层**：让项目能声明“推荐接哪些 MCP Server” 2. **信任层**：由每个开发者自己决定“我是否真的允许这些配置在我的机器上跑” 这个分层的好处是，团队仍然能共享工具清单，但最终执行权限还保留在个人本机手里。
进阶：既然 VS Code 自己也有扩展 API，为什么还要用 MCP，而不是直接写一个扩展？ **参考答案：** 两条路解决的问题不完全一样。 写扩展更像“给 VS Code 造一个原生功能”，你可以深度接入编辑器能力、命令面板、侧边栏、面板 UI，甚至发到 Marketplace。这条路自由度最高，但开发、测试、发布、维护成本也最高。 MCP 则更像“把一个现成外部能力插进来”。如果你的目标只是让 Copilot Agent 能调用 GitHub、数据库、浏览器、内部 API，MCP 的成本明显更低，而且这个 Server 将来不只 VS Code 能用，其他支持 MCP 的客户端理论上也能复用。 所以简单记： - **想快速接外部工具**：优先 MCP - **想做深度 VS Code 原生能力**：优先扩展 API
## 参考资料 1. VS Code 官方文档：MCP servers — （查询日期 2026-04-11） 2. VS Code 官方文档：Model Context Protocol — （查询日期 2026-04-11） 3. VS Code 官方文档：Copilot settings reference — （查询日期 2026-04-11） 4. VS Code 1.99 发布说明 — （查询日期 2026-04-11） 5. VS Code 1.102 发布说明 — （查询日期 2026-04-11） 6. Anthropic 官方文档：MCP in Claude Code — （查询日期 2026-04-11） --- *Source: https://learnagent.wiki/mcp/cards/vscode-setup* *Markdown mirror of https://learnagent.wiki, served as text/markdown for LLM ingestion.*