在 Claude Code 中配置 MCP
一条命令挂载 MCP Server,让终端里的 Claude 也能连接数据库、GitHub、Sentry 等外部工具。
在 VS Code 里把 Copilot Agent 接上 MCP Server,让聊天窗口直接调用 GitHub、浏览器和数据库等外部能力。
内容摘要
如果你平时主要在 IDE 里写代码,那 VS Code 的 MCP 支持很适合你。它的核心价值不是“又多了一个能配 MCP 的客户端”,而是:**让 GitHub Copilot 的 Agent 模式直接长出外部工具手脚**。你不用离开编辑器,就能让 Copilot 去读 GitHub、跑浏览器、查数据库、打开内部文档,甚至把 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 工作流绑得很紧:
Add Context > MCP Resources 加进上下文| 要素 | 作用 |
|---|---|
| 运行前提 | 需要 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 里直接管理 |
最少要满足这几件事:
chat.agent.enabled 或 chat.mcp.access可以先在终端确认 VS Code 版本:
code --version
最常见的做法,是在当前项目根目录创建 .vscode/mcp.json。下面这个示例同时接了一个远程 GitHub MCP Server 和一个本地 Playwright Server:
{
"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-playwrightservers 下面每一项就是一个独立的 MCP Server,Copilot 会把它们暴露出来的能力汇总给 Agent如果你不想手写 JSON,也可以直接用 VS Code CLI 添加:
code --add-mcp '{"name":"playwright","command":"npx","args":["-y","@microsoft/mcp-server-playwright"]}'
配置写完后,VS Code 会发现这些 Server。你可以通过下面几种方式管理它们:
MCP: List Serversmcp.json,直接用文件顶部的操作入口启停MCP 分类如果这是工作区级 Server,第一次启用时通常会弹出信任确认。这里的意思不是“这个协议危不危险”,而是“你是否允许这个仓库里的配置在本机启动外部程序或访问外部服务”。
一个细节要记住:如果 Server 是你直接在
mcp.json里手动写的,VS Code 不一定再额外弹一次 trust 提示,所以配置来源一定要自己把关。
一旦 Server 正常启动,Copilot Chat 就能消费它暴露出的能力:
Add Context > MCP Resources 加进对话上下文最小体验方式:
你:审查一下我当前仓库最近打开的 PR,并用浏览器打开登录页做一次冒烟测试。
Copilot:先调用 GitHub MCP 工具读取 PR,再调用 Playwright MCP 工具打开页面并执行检查。
如果你不想让 Agent 自己挑工具,也可以在输入框里键入 #,明确点名某个 MCP Tool。
VS Code 这套做法最大的实际价值,是能把 MCP 配置当项目配置一起带走。常见做法有两种:
.vscode/mcp.json 提交进仓库,让团队成员拿到相同的 Server 列表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 |
| 工作流重心 | 编辑器内 | 扩展开发 | 终端内 |
核心区别:
| 误区 | 准确理解 |
|---|---|
| 以为装了 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 的支持度不完全一致 |
参考答案:
判断标准就一个:这个 Server 是“项目资产”还是“个人习惯”。
如果它和当前仓库强相关,比如前端仓库统一接 Playwright、后端仓库统一接只读数据库、全团队都要审 GitHub PR,那就更适合放进 .vscode/mcp.json。这样仓库一 clone 下来,大家都能看到同一套 MCP 配置,团队协作成本最低。
如果它是你个人长期复用的工具,比如你自己的知识库、私人 Notion、个人 Sentry、只在自己电脑可用的本地服务,那更适合放到用户级 mcp.json。这样你换项目也能继续用,不会把个人偏好带进团队仓库。
参考答案:
因为 MCP 配置的本质,不只是“描述信息”,而是可能直接启动本地进程、访问外部服务、读写敏感资源的执行入口。
如果仓库里只要出现 .vscode/mcp.json 就自动执行,那你 git clone 一个陌生项目时,IDE 可能立刻在本机启动一堆你没审过的命令。这显然不安全。
所以 VS Code 把这件事拆成两层:
这个分层的好处是,团队仍然能共享工具清单,但最终执行权限还保留在个人本机手里。
参考答案:
两条路解决的问题不完全一样。
写扩展更像“给 VS Code 造一个原生功能”,你可以深度接入编辑器能力、命令面板、侧边栏、面板 UI,甚至发到 Marketplace。这条路自由度最高,但开发、测试、发布、维护成本也最高。
MCP 则更像“把一个现成外部能力插进来”。如果你的目标只是让 Copilot Agent 能调用 GitHub、数据库、浏览器、内部 API,MCP 的成本明显更低,而且这个 Server 将来不只 VS Code 能用,其他支持 MCP 的客户端理论上也能复用。
所以简单记:
优先展示同分类且标签更接近的内容,方便继续串联学习。
一条命令挂载 MCP Server,让终端里的 Claude 也能连接数据库、GitHub、Sentry 等外部工具。
手把手教你在 Claude Desktop 里挂载 MCP Server,5 分钟让 Claude 能读写你的文件。