摘要：VS Code Copilot集成MCP Server的完整配置流程，涵盖GitHub Copilot MCP支持、工具调用配置和AI编程增强，让开发者在VS Code中无缝使用MCP工具链。

第40篇 VS Code Copilot集成 MCP与GitHub Copilot

标签: MCP, VS Code, GitHub Copilot, MCP集成, AI编程

上周有个朋友跑来跟我吐槽，说他在 Claude Desktop 里用 MCP 调了一个数据库查询工具，体验很好，结果回到 VS Code 里用 GitHub Copilot 的时候就想，这玩意儿能不能也接 MCP？我说你算是问对人了，我前阵子刚在项目里把这条路趟了一遍，中间踩了两个特别隐蔽的坑，今天就跟你们好好聊聊。

从一个真实的场景说起

我们团队的项目有一套内部的 API 文档系统，每个接口的参数、返回值、错误码都存在一个内部服务里。以前用 Copilot 写代码的时候，遇到不确定的接口参数，我得切到浏览器查文档，再切回来写代码。来回切换特别打断思路。

后来我想，如果能让 Copilot 直接调一个 MCP Server 去查 API 文档，那岂不是可以在聊天窗口里直接问"这个接口的入参是什么"然后拿到准确结果？我就开始研究 VS Code 里 GitHub Copilot 的 MCP 支持。

说实话，一开始我以为这功能特别复杂，结果发现配置起来比想象的简单，但坑也是真的多。

VS Code 中 MCP 支持的现状

GitHub Copilot 在 VS Code 里的 MCP 支持是通过 chat.mcp 这组配置项实现的。从 2025 年中期开始，VS Code 正式支持在 Chat 面板的 Agent 模式下调用 MCP Server 暴露的工具。

核心机制是这样的，VS Code 内部实现了一个 MCP Client，它会在你启动 Agent 模式对话的时候，根据配置文件去启动对应的 MCP Server 子进程，然后通过 stdio 跟 Server 通信。Copilot 拿到你的问题后，会判断需不需要调 MCP 工具，需要的话就自动调，不需要就用普通的方式回答。

这里有个关键点，MCP 工具只在 Agent 模式下可用，Ask 模式不会触发 MCP 调用。我一开始不知道这个，在 Ask 模式里折腾了半天，心想这 MCP 怎么一点反应都没有。

配置文件编写

VS Code 的 MCP 配置写在 settings.json 里，具体是 chat.mcp.serverSampling 这个字段。下面是一个完整的配置示例，我用的是一个高德地图 MCP Server 和一个自定义的 API 文档查询 Server。

// settings.json 中的 MCP 配置
{
  // MCP 服务器配置区域，所有 MCP Server 都放在这里
  "chat.mcp.serverSampling": {
    "mcpServers": {
      // 高德地图 MCP Server，用于地理信息查询
      "amap-maps": {
        // command 指定启动命令，Windows 下用 cmd
        "command": "cmd",
        // args 是传给 command 的参数，这里用 npx 启动高德 MCP Server
        "args": [
          "/c",
          "npx",
          "-y",
          "@amap/amap-maps-mcp-server"
        ],
        // env 传入 MCP Server 需要的环境变量
        "env": {
          "AMAP_MAPS_API_KEY": "你的高德API_KEY"
        }
      },
      // 自定义的 API 文档查询 MCP Server
      "api-docs": {
        // 用 node 启动我们写的 JS 文件
        "command": "node",
        "args": [
          "C:/mcp-servers/api-docs-server/index.js"
        ],
        "env": {
          "API_DOCS_BASE_URL": "https://internal-docs.mycompany.com"
        }
      }
    }
  },
  // 自动启动 MCP Server 的策略
  // newAndOutdated 表示遇到新的或过期的配置就自动启动
  "chat.mcp.autostart": "newAndOutdated"
}

配置写好后，重启 VS Code 或者重新加载窗口（Ctrl+Shift+P 输入 Reload Window），然后在 Chat 面板里把模式切到 Agent。这时候你打开聊天窗口右下角的小图标，应该能看到已经连接上的 MCP Server 和它们暴露的工具列表。

工具调用验证

配置好了之后，怎么验证 MCP 工具确实能被调用呢？我写了一个特别简单的 MCP Server 来做测试，它只暴露一个工具，就是返回当前时间。这个 Server 用 TypeScript 写的，逻辑非常简单。

// time-server.ts - 一个极简的 MCP Server，只暴露一个时间查询工具
// 依赖: npm install @modelcontextprotocol/sdk

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,      // 工具调用请求的 schema
  ListToolsRequestSchema,     // 工具列表请求的 schema
} from "@modelcontextprotocol/sdk/types.js";

// 创建 MCP Server 实例，指定名称和版本
const server = new Server(
  {
    name: "time-server",      // Server 名称，会显示在 VS Code 的 MCP 面板里
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {},               // 声明此 Server 支持工具能力
    },
  }
);

// 注册 tools/list 处理器，当客户端请求工具列表时触发
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: "get_current_time",         // 工具名称
        description: "获取当前系统时间，返回 ISO 格式字符串",  // 工具描述
        inputSchema: {
          type: "object",
          properties: {
            timezone: {
              type: "string",
              description: "时区，例如 Asia/Shanghai",
            },
          },
        },
      },
    ],
  };
});

// 注册 tools/call 处理器，当客户端调用工具时触发
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  // 根据工具名做分发
  if (name === "get_current_time") {
    // 获取时区参数，默认用本地时区
    const timezone = (args as { timezone?: string })?.timezone || "local";
    const now = new Date();
    // 返回工具调用结果，content 是一个数组
    return {
      content: [
        {
          type: "text",
          text: `当前时间 (${timezone}): ${now.toISOString()}`,
        },
      ],
    };
  }

  // 未知工具返回错误
  throw new Error(`未知工具: ${name}`);
});

// 使用 stdio 传输层启动 Server
const transport = new StdioServerTransport();
await server.connect(transport);

把这段代码保存为 time-server.ts，然后在 settings.json 里加上对应的配置。

// 在 settings.json 的 mcpServers 中添加
"time-server": {
  "command": "npx",
  "args": [
    "tsx",
    "C:/mcp-servers/time-server/time-server.ts"
  ]
}

然后在 Agent 模式的 Chat 窗口里输入"现在几点了"，你会看到 Copilot 自动调用了 get_current_time 这个工具，然后基于返回的时间给你回复。如果看到工具被调用了，说明你的 MCP 配置没问题。

Chat 模式调用 MCP 工具的完整流程

实际用起来的时候，整个调用流程是这样的。

第一步，你在 Chat 窗口输入问题，比如"帮我查一下从北京到上海的驾车距离"。

第二步，Copilot 分析你的问题，发现高德地图 MCP Server 有一个计算距离的工具可以用。

第三步，VS Code 的 MCP Client 向 MCP Server 发送 tools/call 请求，参数是 Copilot 生成的。

第四步，MCP Server 执行实际的 API 调用，拿到结果后返回给 Client。

第五步，Copilot 拿到工具返回的结果，组织成自然语言回复给你。

整个过程中你不需要做任何额外操作，Copilot 自己判断该不该用工具、用哪个工具。这就是 MCP 在 VS Code 里最大的价值，它让 Copilot 从一个只会写代码的助手变成了一个能操作外部系统的 Agent。

与 Claude Desktop 对比

我在 Claude Desktop 和 VS Code Copilot 里都用了同样的 MCP Server，体验差别还是挺明显的。

对比维度VS Code CopilotClaude Desktop
配置位置settings.json 中 chat.mcp.serverSamplingclaude_desktop_config.json
配置格式mcpServers 对象mcpServers 对象（基本一致）
触发方式仅 Agent 模式可用默认可用
自动启动需配置 chat.mcp.autostart默认自动启动
工具可见性右下角图标可查看工具列表对话框上方可查看
多 Server 支持支持，可同时配置多个支持，可同时配置多个
上下文集成可直接在代码编辑中使用结果纯对话场景
调试便利性输出面板有 MCP 日志日志在 ~/Library/Logs
稳定性偶尔有 Server 不启动的情况相对稳定
环境变量传递通过 env 字段传入通过 env 字段传入

从我的使用体验来看，Claude Desktop 在 MCP 的稳定性和易用性上确实更成熟一些，毕竟 Anthropic 是 MCP 协议的提出者。但 VS Code Copilot 的优势在于它跟代码编辑器的深度集成，工具返回的结果可以直接在代码中使用，不用在两个应用之间来回复制。

独家踩坑经验 MCP Server 在 Windows 下启动失败的坑

这个坑我踩了整整一个下午，特别恶心。

事情是这样的，我在 Windows 上配置了一个 MCP Server，command 填的是 npx，args 填的是 ["-y", "@amap/amap-maps-mcp-server"]。配置写好后切到 Agent 模式，发现右下角的 MCP 图标里这个 Server 始终是灰色的，表示没启动成功。

我一开始以为是 API Key 写错了，检查了好几遍没问题。又以为是 npx 没装好，在终端里手动跑了 npx -y @amap/amap-maps-mcp-server，跑得好好的。

后来我去翻 VS Code 的输出面板（Output 面板，选 MCP 频道），发现报了一个错，大意是找不到 npx 这个命令。

这就很诡异了，终端里能跑的命令，VS Code 里怎么就找不到了？

折腾了半天我才搞明白，Windows 下 VS Code 启动子进程的时候，PATH 环境变量跟你 PowerShell 里的 PATH 不完全一样。特别是如果你用 nvm 管理 Node 版本，nvm 的路径可能没被 VS Code 正确继承。

解决办法有两种。

第一种，把 command 从 npx 改成 cmd，args 前面加上 /c npx。

// Windows 下推荐的写法
"amap-maps": {
  "command": "cmd",
  "args": [
    "/c",
    "npx",
    "-y",
    "@amap/amap-maps-mcp-server"
  ],
  "env": {
    "AMAP_MAPS_API_KEY": "你的key"
  }
}

第二种，用 npx 的绝对路径。你可以在终端里执行 where npx 拿到完整路径，然后填到 command 里。

// 用绝对路径的写法
"amap-maps": {
  "command": "C:\\Program Files\\nodejs\\npx.cmd",
  "args": [
    "-y",
    "@amap/amap-maps-mcp-server"
  ],
  "env": {
    "AMAP_MAPS_API_KEY": "你的key"
  }
}

我最后用的是第一种方案，因为更通用。但说实话这个坑真的很隐蔽，因为 VS Code 的错误提示太含糊了，只在 Output 面板里有一行小字，你在 Chat 窗口里根本看不到任何报错。

还有一个相关的坑，如果你配置了 chat.mcp.autostart 为 newAndOutdated，但你的 Server 启动失败了，VS Code 不会在 Chat 窗口里告诉你，它只是默默地把那个 Server 标记为不可用。你必须主动去 Output 面板看日志才知道出了什么问题。所以我的建议是，配置完 MCP Server 之后，第一件事就是去 Output 面板看一眼有没有报错。

完整可运行项目 智能代码审查助手

最后给大家分享一个我在项目里实际用的完整方案。这是一个基于 MCP 的智能代码审查助手，它能读取 Git 变更内容，结合自定义规则给出审查意见。

这个项目包含一个 MCP Server（用 TypeScript 写）和对应的 VS Code 配置。Server 暴露三个工具，获取 Git diff、获取文件内容、查询审查规则。

// code-review-server.ts - 智能代码审查 MCP Server
// 依赖: npm install @modelcontextprotocol/sdk simple-git

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
import simpleGit from "simple-git";
import { readFileSync } from "fs";
import { join } from "path";

// 初始化 Git 操作实例，指向当前工作目录
const git = simpleGit(process.cwd());

// 创建 MCP Server
const server = new Server(
  {
    name: "code-review-server",
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {},
    },
  }
);

// 审查规则，实际项目中可以从数据库或配置文件读取
const REVIEW_RULES = [
  {
    id: "rule-001",
    rule: "函数参数超过5个时需要重构",
    severity: "warning",
  },
  {
    id: "rule-002",
    rule: "禁止使用 any 类型",
    severity: "error",
  },
  {
    id: "rule-003",
    rule: "API 调用必须有错误处理",
    severity: "error",
  },
  {
    id: "rule-004",
    rule: "注释率不低于30%",
    severity: "warning",
  },
];

// 注册工具列表处理器
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        // 工具1: 获取 Git 暂存区的 diff
        name: "get_git_diff",
        description: "获取 Git 暂存区的代码变更内容，返回 diff 字符串",
        inputSchema: {
          type: "object",
          properties: {
            staged: {
              type: "boolean",
              description: "是否只获取暂存区的变更，默认 true",
            },
          },
        },
      },
      {
        // 工具2: 读取指定文件内容
        name: "read_file",
        description: "读取项目中指定路径的文件内容",
        inputSchema: {
          type: "object",
          properties: {
            path: {
              type: "string",
              description: "文件相对路径，例如 src/index.ts",
            },
          },
          required: ["path"],
        },
      },
      {
        // 工具3: 查询代码审查规则
        name: "get_review_rules",
        description: "获取所有代码审查规则列表",
        inputSchema: {
          type: "object",
          properties: {},
        },
      },
    ],
  };
});

// 注册工具调用处理器
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;
  const argObj = args as Record<string, unknown>;

  switch (name) {
    case "get_git_diff": {
      // 根据参数决定获取暂存区还是工作区的 diff
      const staged = argObj?.staged !== false;
      // 调用 simple-git 获取 diff
      const diff = staged
        ? await git.diff(["--cached"])
        : await git.diff();
      return {
        content: [
          {
            type: "text",
            // 如果没有变更，返回提示信息
            text: diff || "没有检测到代码变更",
          },
        ],
      };
    }

    case "read_file": {
      const filePath = argObj?.path as string;
      try {
        // 拼接完整路径并读取文件
        const fullPath = join(process.cwd(), filePath);
        const content = readFileSync(fullPath, "utf-8");
        return {
          content: [
            {
              type: "text",
              text: content,
            },
          ],
        };
      } catch (err) {
        // 文件读取失败时返回错误信息
        return {
          content: [
            {
              type: "text",
              text: `读取文件失败: ${(err as Error).message}`,
            },
          ],
          isError: true,
        };
      }
    }

    case "get_review_rules": {
      // 返回所有审查规则，格式化为 JSON 字符串
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(REVIEW_RULES, null, 2),
          },
        ],
      };
    }

    default:
      throw new Error(`未知工具: ${name}`);
  }
});

// 启动 Server
const transport = new StdioServerTransport();
await server.connect(transport);

对应的 VS Code 配置如下。

// settings.json 配置
{
  "chat.mcp.serverSampling": {
    "mcpServers": {
      "code-review": {
        "command": "cmd",
        "args": [
          "/c",
          "npx",
          "tsx",
          "C:/mcp-servers/code-review-server.ts"
        ]
      }
    }
  },
  "chat.mcp.autostart": "newAndOutdated"
}

配置好之后，你在 Agent 模式的 Chat 窗口里输入"帮我审查一下当前 Git 变更的代码"，Copilot 就会自动调用 get_git_diff 拿到变更内容，调用 get_review_rules 拿到审查规则，然后逐条对照分析，最后给出审查意见。

我在项目里用了一个月，最大的感受是它确实能减少人工审查的工作量。以前每次提交代码前要自己检查一遍规则，现在直接在 Chat 窗口问一句就行。不过也有个问题，如果 diff 特别大，Copilot 有时候会漏掉一些规则，需要你追问一句"还有没有其他问题"。

小结

这篇文章我们聊了 VS Code 里 GitHub Copilot 的 MCP 支持，从配置文件编写到工具调用验证，再到完整的代码审查项目。核心要点有几个。

第一，MCP 配置写在 settings.json 的 chat.mcp.serverSampling 里，格式跟 Claude Desktop 基本一致。

第二，MCP 工具只在 Agent 模式下可用，Ask 模式不触发。

第三，Windows 环境下启动 MCP Server 最好用 cmd /c 的方式，避免 PATH 找不到的问题。

第四，配置完一定要去 Output 面板看日志，这是排查 MCP 问题最快的方式。

下一篇我们换个方向，聊聊怎么通过桥接让 ChatGPT 也能用上 MCP，那个方案会更复杂一些，但思路特别有意思。

相关推荐

# copilot # github # MCP
Logo
MCP技术社区

欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！

更多推荐

Google能索引，AI却抓不到

很多技术团队有个错觉：只要Google能正常收录，内容就没问题。但现实是，你的页面在Google搜索结果里好好的，在ChatGPT、Perplexity、Claude的答案里却像从未存在过一样。

avatar MCP技术社区
cover

Windows 下部署 New API 中转站全过程实录（含 6 个真实踩坑）

avatar MCP技术社区

初识智能体

在过去两年中，几乎所有人都体验过大语言模型（如 ChatGPT、Claude、DeepSeek）的强大能力：写周报、润色邮件、解答编程疑难。被动响应：你问一句，它答一句。如果你的 Prompt 没有写清楚约束条件，它无法主动追问或修正目标。知行脱节：大模型能用流畅的文字告诉你“如何部署一个高可用 K8s 集群”，但它无法替你登录服务器敲下命令、查看报错日志并自动回滚。信息孤岛：大模型的知识止步于预

avatar MCP技术社区