MCP协议实战：Copilot连接GitHub

通过一个实际案例理解 MCP

最近我一直在学习 Model Context Protocol（MCP），希望不仅仅是停留在理论层面，而是真正理解它。

与其只是阅读 MCP 的相关文章，我决定做一个实践集成：

将 VS Code 中的 GitHub Copilot 通过 GitHub MCP Server 连接到 GitHub。

这帮助我理解了 AI Agent 如何与外部系统交互，以及为什么 MCP 正在成为 AI 生态中越来越重要的一部分。

MCP（Model Context Protocol）是一种标准化的协议，允许 AI 应用和 Agent 与外部工具、服务和数据源进行通信。

举例来说，一个 AI Agent 可能需要与以下内容交互：

内部文档

如果没有标准的集成机制，每个 AI 应用可能都需要为每个服务单独开发定制化的集成。

MCP 提供了一种标准化的方案。

简化的架构如下：

AI Application / Agent
(Claude, Copilot, ChatGPT)
          │
          │ MCP Protocol
          ▼
      MCP Server
          │
          │ API / SDK / Service Integration
          ▼
External System
(GitHub, AWS, Jira, Database)

MCP 与 REST API 有何相似之处？

当我第一次尝试理解 MCP 时，我将它与传统的 REST API 架构进行了对比。

传统的 API 通信

Client
(Postman / Application)
        │
        │ HTTP
        ▼
API Server
        │
        ▼
Application / Service

例如，在使用 GitHub REST API 时，开发者可能会手动调用类似这样的端点：

GET /repos/{owner}/{repo}/issues

客户端需要知道：

要调用哪个 API 端点

使用哪种 HTTP 方法

哪些参数是必需的

认证如何工作

如何处理响应

使用 MCP 时，交互可以更加面向 Agent。

AI Agent
   │
   │ MCP
   ▼
MCP Server
   │
   ▼
External Service

不需要手动调用 API 端点，而是可以直接告诉 AI：

"显示这个仓库中所有打开的 issue。"

AI Agent 就能确定哪个可用工具是合适的，并通过 MCP Server 使用它。

在这个实验中，我使用了：

GitHub 认证

架构如下：

Developer
    │
    ▼
VS Code
    │
    ▼
GitHub Copilot
    │
    │ MCP
    ▼
GitHub MCP Server
    │
    │ GitHub APIs / Services
    ▼
GitHub

GitHub Copilot 作为由 AI 驱动的客户端，可以通过 MCP Server 暴露的工具来执行操作。

第一步：配置 GitHub MCP Server

在 VS Code 中，MCP Server 可以通过 mcp.json 配置。

对于远程 GitHub MCP Server，配置类似于：

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

配置完成后，VS Code 就可以连接到 MCP Server。更多配置信息可以查看这里。

第二步：GitHub 身份验证

由于 MCP Server 需要获得访问 GitHub 资源的权限，因此需要身份验证流程。

大致流程如下：

VS Code
   │
   ▼
GitHub Copilot
   │
   ▼
GitHub MCP Server
   │
   │ Authentication Required
   ▼
GitHub OAuth
   │
   ▼
User Approves Access
   │
   ▼
MCP Server Can Access Authorized Resources

MCP 定义了 AI 应用与 MCP Server 之间的通信方式。

身份验证和授权决定了：

你是谁，你被允许访问什么？

连接 MCP Server 之后，我就可以向 GitHub Copilot 提问，例如：

"显示我打开的 GitHub issue。"

"获取这个仓库的信息并解释它的架构。"

"创建一个标题为 'Add Terraform deployment documentation' 的 GitHub issue。"

在幕后，交互过程大致如下：

1. User
      │
      │ "Show me open issues"
      ▼

2. GitHub Copilot / AI Agent
      │
      │ Determines GitHub data is required
      ▼

3. MCP Client
      │
      │ MCP Request
      ▼

4. GitHub MCP Server
      │
      │ Interacts with GitHub
      ▼

5. GitHub
      │
      │ Returns Data
      ▼

6. GitHub MCP Server
      │
      │ MCP Response
      ▼

7. Copilot
      │
      ▼

8. User receives the result

让我更清晰理解 MCP 的一件事，是认识到 MCP Server 可以向 AI Agent 暴露各种能力。

例如，一个 MCP Server 可能提供以下工具：

get_repository()
list_issues()
create_issue()
get_pull_request()

它还可能提供对资源的访问，例如：

仓库信息

基础设施信息

AI Agent 可以发现 MCP Server 提供的可用能力，并根据用户请求选择合适的工具来使用。

作为一名从事 Cloud 和 TechOps 工作的人，我发现 MCP 特别有趣，因为我可以想象它在许多实际场景中的用途。

GitHub Copilot / AI Agent
           │
           ├── GitHub MCP Server
           │
           ├── AWS MCP Server
           │
           ├── Jira MCP Server
           │
           ├── Monitoring MCP Server
           │
           └── Internal Documentation MCP Server

想象一下，向一个 AI Agent 提问：

"一次生产部署失败了。请检查 GitHub 的 pull request，调查 AWS 环境，查看监控告警，并根据你的发现创建一个 Jira 事件单。"

AI Agent 理论上可以通过多个 MCP Server 与多个系统进行交互。

当然，适当的身份验证、授权、审批机制和安全控制是必不可少的，尤其是当 Agent 可以在生产环境中执行操作时。

目前我最容易理解 MCP 的方式是：

MCP 是一个标准化的集成层，允许 AI Agent 发现并与外部工具和数据源进行交互。

一个简化的对比如下：

传统开发模式：

Developer
   │
   ▼
Application Code
   │
   ▼
REST API
   │
   ▼
External Service

而启用 MCP 的工作流可以是这样的：

User
   │
   ▼
AI Agent
   │
   ▼
MCP Client
   │
   ▼
MCP Server
   │
   ▼
Tools / APIs / Data / External Services

MCP 提供了一种通用协议来连接 AI 应用和外部服务，而无需为每个 AI 应用和外部服务都构建完全定制化的集成。