MCP 是什么？Model Context Protocol 实用入门

如果你最近在用 AI 编程助手或聊天应用，很可能在功能列表里见过“支持 MCP”。Model Context Protocol（模型上下文协议，简称 MCP）是 Anthropic 在 2024 年底推出的开放标准，规定了 AI 应用如何连接外部工具和数据。有了它，工具作者不用再为每个应用分别开发插件，只要写一个 MCP Server，所有兼容 MCP 的应用都能直接使用。

这个生态发展得很快。在 AgentIndex 收录的 2,807 个开源工具中，有 1,389 个在名称或标签里提到了 MCP，其中 138 个的 GitHub star 数超过 1,000。本文介绍 MCP 的工作原理，演示如何接入几个真实的 Server，并说明从第一天起就应该养成的安全习惯。

MCP 解决了什么问题

大模型本身只知道训练数据里的内容，以及你贴进对话里的东西。要真正帮你干活，它需要读取最新的文档、查看你的代码仓库、查询数据库，或者在网页上点击操作。在 MCP 出现之前，这些集成需要为每个应用单独开发：给这个编辑器做一个插件，再给那个聊天客户端做一个扩展。

MCP 把这件事变成了“多对多”的标准：集成只需要写一次（作为 Server），就能在 Claude Code、Cursor、VS Code、Gemini CLI 以及其他支持该协议的客户端里使用。

MCP 的基本结构

MCP 里有三种角色：

• Host（宿主）：你直接使用的应用，比如 Claude Desktop、Claude Code、Cursor 或 VS Code。
• Client（客户端）：Host 内部的连接器。Host 每连接一个 Server，就会创建一个对应的 Client。
• Server（服务端）：向模型提供能力的程序，可以运行在你的电脑上，也可以是远程的网络服务。

一个 Server 可以提供三类能力：

• Tools（工具）：模型可以自主决定调用的函数，比如“搜索文档”“创建 Issue”“点击这个按钮”。
• Resources（资源）：应用可以读取并加入模型上下文的数据，比如文件或数据记录。
• Prompts（提示模板）：用户可以选用的、可复用的提示词模板。

Client 和 Server 之间使用 JSON-RPC 格式通信，传输方式有两种：

搞清楚一个 Server 用的是哪种传输方式很重要：本地 stdio Server 拥有和你的用户账号相同的权限，而远程 Server 能看到你发给它的所有数据。

接入你的第一个 MCP Server

下面用目录中三个常用的 Server 举例。命令都来自各项目自己的 README，最新选项请以 README 为准。

本地 Server：Playwright MCP

Playwright MCP 让模型可以通过 Playwright 操作真实的浏览器，它通过 stdio 在本地运行。在 Claude Code 中，一条命令就能添加：

claude mcp add playwright npx @playwright/mcp@latest

在用 JSON 文件配置的客户端里，比如 Cursor（全局配置 ~/.cursor/mcp.json，或项目内的 .cursor/mcp.json）和 Claude Desktop，同一个 Server 的写法是：

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

远程 Server：Context7

Context7 会把最新的、对应具体版本的库文档放进 AI 助手的上下文，减少模型编造 API 的情况。它提供远程 Server，地址是 https://mcp.context7.com/mcp，用 API Key 作为 Bearer Token 认证。在 Claude Code 中：

claude mcp add --transport http context7 https://mcp.context7.com/mcp \
  --header "Authorization: Bearer YOUR_API_KEY"

在 JSON 配置的客户端里，远程 Server 用 url 和 headers 代替 command：

{
  "mcpServers": {
    "context7": {
      "url": "https://mcp.context7.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

Context7 还提供 npx ctx7 setup 命令，登录后会自动为 Cursor、Claude Code 或 OpenCode 写好上面的配置。

有写权限的 Server：GitHub MCP Server

官方的 GitHub MCP Server 让 Agent 可以读取仓库、Issue 和 Pull Request，也能创建和修改它们。GitHub 提供了托管的远程版本，地址是 https://api.githubcopilot.com/mcp/，支持 OAuth 或个人访问令牌（PAT）认证；你也可以用 Docker 自己运行。它的 README 里有两个值得了解的选项：

• --toolsets：限定开放哪些 GitHub 功能组，比如只开放 repos,issues,pull_requests。工具越少，占用的上下文也越少，模型选择工具时也更准确。
• --read-only：只开放只读操作，Agent 无法修改仓库、Issue 或 Pull Request。

建议先从只读权限开始，等流程跑顺、确认可信之后，再开放写权限。

必须养成的安全习惯

MCP Server 是带着真实权限在运行的，安装它和安装其他软件一样需要谨慎。

1. 弄清楚代码在哪里运行。 stdio Server 是本地程序，拥有你的用户账号的文件和网络访问权限。优先选择来源可靠的 Server，敏感场景下锁定版本号。
2. 只给最小权限。 使用只读模式、功能组过滤和权限范围尽量小的令牌。能访问所有仓库的个人令牌，大多数情况下并不需要。
3. 不要把密钥写进共享文件。 项目级配置文件经常会提交到 git。令牌应该放在环境变量里，或者使用客户端提供的密钥输入机制。
4. 把工具返回的内容当作不可信输入。 网页、Issue 和文档里可能藏着针对模型的指令（提示词注入）。对于会写入数据或执行命令的操作，批准前先检查。
5. 及时移除不用的 Server。 每接入一个 Server，它的工具描述都会占用模型的上下文。Server 太多会降低工具选择的准确性，也会拖慢每一次请求。

什么时候不一定要用 MCP

MCP 并不是给 Agent 增加能力的唯一方式。Playwright 团队在 README 中提到，编程 Agent 越来越倾向于使用“命令行工具 + Skills”的方式，因为一条简短的 CLI 命令消耗的 token，远少于把大量工具定义和页面快照塞进上下文。Context7 同样提供了不依赖 MCP 的“CLI + Skill”模式。

一个实用的判断标准：如果你希望某项能力能在多个客户端中通用，或者工具需要结构化、可交互的访问（比如浏览器会话、需要认证的 API），就用 MCP；如果编程 Agent 用几条简洁的命令就能完成同样的事，就用 CLI 或 Skill。

下一步

• 浏览 MCP Servers 分类，以及 awesome-mcp-servers 这类社区合集，找到适合你技术栈的 Server。
• 如果想让编程 Agent 在 Chrome 里检查和调试页面，可以试试 Chrome DevTools MCP。
• 想用 Python 自己开发 Server 的话，FastMCP 是编写 MCP Server 和 Client 的常用框架。

接入的 Server 越多，MCP 能发挥的价值越大，但需要信任的范围也越大。建议先从一两个维护良好的 Server 开始，把权限收紧，再逐步扩展。