AI 编程教程中文版
官方教程中文版MCP 与外部工具

MCP 与外部工具

把 GitHub MCP Server、IDE MCP 配置、toolsets、registry 和企业部署边界串成可落地流程。

MCP(Model Context Protocol,模型上下文协议)不是“给 Copilot 装更多插件”,而是把外部系统以可发现、可授权、可审计的工具形式接入 agent。真正要管住的是三件事:谁提供工具、工具能访问什么、结果怎么验证。

这组页面按 GitHub 和 VS Code 官方文档整理 MCP 的实战边界:从概念、GitHub MCP Server、IDE Chat 使用,到 enterprise、toolsets 和 registry。

阅读目标:读完本组后,你应该能判断一个外部系统是否应该接 MCP、应该放工作区还是个人配置、应该开放哪些 toolsets、以及上线前要留哪些审计证据。

1. 一张图看清 MCP

flowchart TD
    User["开发者任务"] --> Chat["Copilot Chat / Agent"]
    Chat --> Client["MCP client"]
    Client --> Server["MCP server"]
    Server --> Tools["Tools"]
    Server --> Resources["Resources"]
    Server --> Prompts["Prompts"]
    Tools --> External["GitHub / 文档 / API / 数据库 / 内部系统"]
    External --> Evidence["结果、日志、权限、错误信息"]
    Evidence --> Chat

    style Chat fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Server fill:#dcfce7,stroke:#16a34a,stroke-width:2px
    style External fill:#fef3c7,stroke:#d97706,stroke-width:2px

2. 本组页面

3. 推荐接入顺序

  1. 先定义上下文缺口:缺 issue、PR、文档、网页、数据库还是内部 API。
  2. 先接只读工具:验证 Copilot 能正确读取上下文。
  3. 再开写工具:只开放具体任务需要的最小 toolset。
  4. 再做共享配置:团队级用 .vscode/mcp.json,个人级用 user profile。
  5. 最后做企业治理:registry、server access、toolsets、PAT/OAuth、日志和回滚。

不要为了“能力多”一次性启用所有 server。MCP 越多,agent 可做的动作越多,排障和审计成本也越高。

4. 上线前检查

  • Server 来源可信,publisher、镜像、脚本、网络目标都能解释。
  • 工具清单明确,不默认启用 all
  • 写操作需要人工确认或有回滚路径。
  • Token 不写进仓库,使用 input variables、env 或受控凭据。
  • 组织策略允许 MCP,且成员知道哪些工具被禁用。
  • 日志能定位问题来自 Copilot、MCP server 还是外部系统。
深读:MCP 不是 prompt engineering 的替代品

Prompt engineering 解决的是“怎么把任务说清楚”。MCP 解决的是“agent 能不能拿到外部系统的真实上下文并执行工具”。

如果没有稳定任务目标,MCP 只会放大错误动作;如果没有权限边界,MCP 会把一次 Chat 变成跨系统操作风险。

本组自检

读完整组后,回答 4 个问题:

  1. 这个 MCP server 解决哪个具体上下文缺口?
  2. 它的工具是只读、写入、审批,还是高风险操作?
  3. 它应该放工作区、个人 profile,还是企业 registry?
  4. 出问题时能否从日志、权限、外部系统状态中定位责任边界?

通过标准:每个 MCP server 都有明确用途、最小权限、验证任务和回滚路径。

官方来源

接下来去哪

本页目录