MCP（Model Context Protocol）详解：如何为你的 AI Agent 配置数据源？

一句话导读：Agent 能写代码，却读不到你的 GitHub Issue、数据库 schema 和内部文档——问题往往不在模型，而在「数据从哪来」没人讲清楚。 本文从 MCP 协议原理讲起，覆盖架构分层、Tools / Resources / Prompts 三大能力、stdio 与 HTTP 两种传输，再到 Cursor 与 Claude Code 的配置写法与验收清单；读完你能独立把常用数据源接进 Agent，而不必为每个 SaaS 单独写胶水代码。

延伸阅读：Claude Code MCP 安装教程 · 20 个 MCP Server 推荐 · 权限最小暴露

MCP 是什么？它解决什么问题？

Model Context Protocol（MCP，模型上下文协议）是 Anthropic 在 2024 年底开源的开放标准，目标很直接：让 AI 应用（Host）能以统一、可审计的方式连接外部世界——代码仓库、数据库、文档站、工单系统、浏览器——而不必为每个数据源各写一套自定义集成。

在 MCP 出现之前，团队常见两条路：

• 人肉搬运上下文——把 Issue 链接、SQL 结果、API 响应复制进聊天框。准确但慢，且无法规模化。
• 自研 Function Calling——为 GitHub、Postgres、Notion 各写一套 tool schema 与鉴权。灵活但维护成本高，换客户端（Cursor → Claude Code）往往要重写。

MCP 走的是第三条路：把「数据源 ↔ Agent」的接口标准化。你配置一个 GitHub MCP Server，Cursor、Claude Code、VS Code Copilot、OpenAI Codex 都能复用；社区已有上千个现成 Server，覆盖主流 SaaS 与开发工具。

三层架构：Host、Client、Server

理解 MCP 配置，先看清三个角色如何协作：

一次典型的调用链如下：你在 Cursor 里问「PR #42 改了哪些文件？」→ Host 把问题交给大模型 → 模型决定调用 mcp__github__get_pull_request → Client 通过 stdio 或 HTTP 把请求发给 GitHub MCP Server → Server 调 GitHub API 返回结构化 JSON → 模型基于真实数据生成回答。

注意：你配置的是 Server 的连接方式（命令、URL、环境变量），Host 会自动发现它暴露了哪些工具。不需要在 prompt 里手写 API 文档——Server 启动时会通过 tools/list 把能力清单推给 Client。

三大能力原语：Tools、Resources、Prompts

MCP Server 向 Agent 暴露三类能力，对应不同的数据源接入模式：

Tools（工具）——「让 Agent 执行动作」

最常用。每个 Tool 有名称、描述、输入 schema（JSON Schema），Agent 在推理过程中按需调用。例如 GitHub MCP 的 search_code、Playwright MCP 的 browser_click、数据库 MCP 的 execute_query。

配置数据源时，90% 的场景都在选 Tool 型 Server：读仓库、查表、发 HTTP、操作浏览器。

Resources（资源）——「让 Agent 读取静态上下文」

Resources 是可寻址的数据片段，类似「带 URI 的只读文件」。Server 声明 file://docs/api.md 或 db://schema/users，Host 可在对话开始前或过程中拉取内容注入上下文，而无需 Agent 主动「猜」该调哪个 Tool。

适合：项目 README、OpenAPI spec、数据库 schema 快照、配置模板等相对稳定、可枚举的知识。

Prompts（提示模板）——「预置工作流入口」

Server 可暴露命名 Prompt 模板（含参数），用户在 Host 里一键触发「Code Review」「写迁移脚本」等固定流程。社区 Server 采用率低于 Tools，但适合团队把 SOP 封装成可复用入口。

数据源类型与常见 MCP Server 映射

下面这张表帮你把「我想接什么」快速映射到「装哪个 Server」。更完整的 20 款清单见 MCP Server 推荐。

传输层：stdio 与 HTTP，该选哪种？

MCP Client 与 Server 之间通过 JSON-RPC 2.0 通信。2026 年主流有两种传输：

stdio（标准输入输出）

Host 以子进程方式启动 Server，例如 npx -y @modelcontextprotocol/server-github，通过 stdin/stdout 交换消息。优点：配置简单、无需开放端口、适合本地开发。缺点：每个 Server 占一个进程；部分全量 Docker 版工具数过多，可能触发 Cursor 约 40 工具上限。

Streamable HTTP / SSE（远程）

Server 运行在远端（或官方托管），Client 通过 HTTPS 连接，常用 OAuth 完成授权。GitHub、Supabase、Linear、Sentry 等官方均提供 Remote 版。优点：工具集精简、无需本地装 Node/Docker、token 由 OAuth 托管。缺点：依赖网络；企业内网需确认出站策略。

在 Cursor 里配置数据源

Cursor 的 MCP 配置位于 Settings → MCP，或直接编辑 ~/.cursor/mcp.json。结构为 mcpServers 对象，每个 Server 一个条目。

示例 1：本地 stdio — Fetch MCP

{
  "mcpServers": {
    "fetch": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-fetch"]
    }
  }
}

示例 2：本地 stdio — GitHub MCP（PAT）

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxx"
      }
    }
  }
}

更推荐在 Cursor UI 里添加 GitHub 官方 Remote MCP（OAuth），工具更少、无需手填 PAT。PAT 务必细粒度只读，且不要提交到 git。

示例 3：Context7（文档数据源）

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

保存后重启 Cursor，在 Settings → MCP 面板查看 Server 状态是否为绿色 Connected。Agent 模式下可直接问「查一下 Next.js 15 的 middleware 写法」——若配置正确，模型会调用 Context7 而非幻觉 API。

在 Claude Code 里配置数据源

Claude Code 使用 ~/.claude.json（用户级）或项目根目录 .mcp.json（项目级）。配置结构与 Cursor 类似，但字段名与路径略有差异。

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxx"
      }
    },
    "codegraph": {
      "command": "codegraph",
      "args": ["mcp"]
    }
  }
}

修改配置后必须完全退出 Claude Code 再启动；在仓库根目录运行 claude，会话内输入 /mcp 查看已连接 Server 与工具列表。成功标志：出现 mcp__github__*、mcp__codegraph__* 等前缀工具。

分步图文见 Claude Code MCP 安装教程；三连通架构见 MCP 总览。

项目级 vs 用户级：配置写在哪？

最佳实践：把凭据与用户偏好放用户级（不进 git）；把与仓库绑定的数据源（CodeGraph 索引路径、项目文档 Server）放项目级并提交 .mcp.json，让队友 clone 即用。敏感 token 用环境变量引用，例如 "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PAT}" }，由 shell 或 CI 注入。

配置验收：让 Agent 真的用上数据源

配完不等于能用。按下面清单逐项验收：

1. 连通性 — Cursor：Settings → MCP 绿灯；Claude Code：/mcp 列出 Server 且无 error。
2. 工具可见 — 确认目标 Tool 名称存在（如 mcp__github__search_code）。
3. 冒烟任务 — 用一句明确指令触发工具，例如「用 GitHub MCP 列出本仓库 open issues」或「用 Context7 查 Prisma 最新 migrate 语法」。
4. 失败可观测 — 若 Agent 没调用工具，检查是否工具过多、描述不清晰，或任务太模糊；必要时在 prompt 里写「请使用 GitHub MCP」。
5. 权限边界 — 故意问一个无权限操作（如删仓库），确认 Server 返回 403 而非静默成功。

权限与安全边界

每接一个数据源，等于给 Agent 开了一扇通往外部系统的门。核心原则：默认只读，写操作显式开启，生产环境隔离。

• GitHub PAT — 细粒度 token，仅授权目标仓库；Issues/Contents 只读即可覆盖多数开发场景。
• 数据库 DSN — 开发库用只读角色；绝不要把生产可写连接串写进项目级配置。
• Filesystem MCP — args 里限定项目根目录，禁止指向 $HOME 或 /。
• 内网 API — 用预发只读端点；Claude Code 工作区不加载生产 .env。

完整策略矩阵与攻击链分析见 MCP 权限最小暴露。

常见故障排查

常见问题

MCP 和 Function Calling 有什么区别？

Function Calling 是单次 API 请求里的工具声明，通常与特定模型/厂商绑定。MCP 是持久化的 Server 连接与开放协议，一次配置多客户端复用，并由社区维护生态。你可以把 MCP 理解为「标准化的、可插拔的 Function Calling 运行时」。

可以自己写 MCP Server 吗？

可以。官方提供 TypeScript（@modelcontextprotocol/sdk）、Python 等 SDK。典型场景：接入公司内部 Wiki、工单 API、专有数据湖。最小 Server 只需实现 tools/list 与 tools/call，用 stdio 传输即可在 Cursor 里调试。

MCP 会把数据发给模型厂商吗？

Tool 调用的结果会进入对话上下文，随你的请求发给 Host 所使用的大模型 API——这是 Agent 工作的必要部分。MCP 本身不额外「上传」数据；风险在于你给了 Server 什么权限（能读哪些仓库、能执行什么 SQL）。按最小权限配置即可控制暴露面。

2026 年应该先接哪几个数据源？

多数开发者从 Context7（文档）+ GitHub（仓库）+ Playwright（浏览器验证）起步。写后端加 Supabase 或 DBHub；团队用 Linear/Notion 再按需叠加。详见 20 个 MCP Server 推荐。