介绍MCP：
在 MCP 出现之前，如果你想让一个 AI 访问你的 GitHub 仓库、查询你的数据库、或者读取你本地的文件，你得为每一个工具单独写一套集成代码。每个 AI 产品有自己的插件系统，每个工具有自己的 API 格式，互相之间完全不通用。
MCP（Model Context Protocol）做的事情很简单：它定义了一套标准的通信协议，让 AI 客户端和外部工具之间可以用同一种”语言”对话。你可以把它想象成 AI 世界的 USB-C 接口——不管你是什么设备，插上就能用。
Anthropic 在 2024 年初把 MCP 开源发布，紧接着 OpenAI 在 2025 年 3 月宣布在 ChatGPT 中支持 MCP，Google 也在 4 月确认了 Gemini 的支持计划。到今天，Block、Replit、Sourcegraph 等一大批公司都已经有了自己的 MCP 实现。这个协议已经从 Anthropic 的”自家标准”变成了行业共识。
架构很简单：Client、Server、Protocol
MCP 的架构其实并不复杂，核心就三个角色。
MCP Client 就是你正在用的 AI 应用，比如 Claude Desktop、Claude Code、Cursor、VS Code 里的 Copilot，或者 OpenAI 的 Codex CLI。它负责向外发送请求，问 MCP Server 要信息或者执行操作。
MCP Server 就是那个提供能力的”适配器”。它可以是一个本地运行的小程序，也可以是一个远程部署的 HTTP 服务。它把某个工具的功能——比如查 GitHub Issue、读本地文件、查数据库——包装成标准化的接口暴露出来。
所有通信都基于 JSON-RPC 2.0 协议。Client 发一个请求，Server 返回一个响应，格式统一，逻辑清晰。
一个典型的连接生命周期是这样的：Client 先发一个初始化请求，告诉 Server 自己支持什么版本和能力；Server 回复自己的版本和能力；Client 确认收到，然后正常的消息交换就开始了。
传输层：三种方式，怎么选
这是很多人最困惑的地方。MCP 定义了几种不同的传输方式，每种适用于不同的场景。
stdio：本地开发的首选
stdio 是最简单也最常用的传输方式。它的工作原理就跟你在终端里运行一个命令行程序差不多：Client 把 MCP Server 作为一个子进程启动，然后通过标准输入（stdin）发送消息，通过标准输出（stdout）接收消息。
这种方式的好处很明显。启动快、延迟低、不需要网络配置、不需要端口管理。你在本地装一个 npm 包或者 Python 包，直接就能用。绝大多数你在社区看到的 MCP Server，默认走的都是 stdio。
但它的局限性也很明显——只能在本地用。MCP Server 必须安装在你自己的机器上，没法多人共享，也没法部署到云端。
SSE：已经过时的远程方案
SSE（Server-Sent Events）是 MCP 最早期的远程传输方案，定义在 2024 年 11 月的协议版本中。它需要两个端点：一个 SSE 端点用于建立持久连接让 Server 推送消息，一个 HTTP POST 端点用于 Client 向 Server 发送请求。
这个方案的问题在于，它要求维持一条永久的连接。连接一旦断开，所有状态都会丢失。而且两个端点的设计增加了部署和调试的复杂度。
2025 年 3 月的协议更新已经把 SSE 标记为”已弃用”，取而代之的是 Streamable HTTP。但你在现有的很多教程和配置里还会看到 SSE 的身影，因为不少 MCP Server 还没来得及迁移。
Streamable HTTP：现在的推荐方案
Streamable HTTP 在 2025 年 3 月 26 日的协议版本中被引入，是目前推荐的远程传输方式。它解决了 SSE 的所有痛点：只需要一个 HTTP 端点，同时支持 POST 和 GET 方法，支持可选的 SSE 流式传输，还有 Session ID 机制来维护状态。
具体来说，Client 向一个统一的 MCP 端点发送 HTTP POST 请求，Server 可以直接返回 HTTP 响应，也可以选择用 SSE 流式推送多条消息。这种设计让简单的请求-响应交互和复杂的流式通信都能在同一个架构下实现。
如果你现在要构建一个新的远程 MCP Server，直接用 Streamable HTTP 就行。如果你有已经在线运行的 SSE Server，可以同时支持两种传输方式来保持向后兼容。TypeScript SDK 从 1.10.0 版本开始就支持 Streamable HTTP 了。
简单总结一下选择逻辑：本地工具用 stdio，远程服务用 Streamable HTTP，SSE 只在兼容老服务器时才用。
各工具的 MCP 配置：大同中有小异
虽然所有工具都在用 MCP 协议，但每个工具的配置方式却各有各的风格。下面我把主流工具的配置方式拆开来讲。
Claude Desktop：JSON 配置文件
Claude Desktop 的 MCP 配置通过一个 JSON 文件来管理。在 macOS 上，这个文件的路径是 ~/Library/Application Support/Claude/claude_desktop_config.json，在 Windows 上是 %APPDATA%\Claude\claude_desktop_config.json。
一个典型的配置长这样：
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxx"
}
}
}
}
注意 Claude Desktop 传统上主要支持 stdio 方式的本地 Server。如果你想连远程 SSE Server，需要借助 mcp-remote 这样的 npm 包做桥接。不过随着协议的演进，Claude Desktop 现在也可以通过”连接器（Connectors）”功能添加远程 Server。
每次修改配置之后，必须重启 Claude Desktop 才能生效。
Claude Code：CLI 优先，三种作用域
Claude Code 的 MCP 配置方式最灵活，也最适合开发者的工作流。它提供了命令行工具来管理 MCP Server，同时支持三种作用域（scope）。
添加一个 Server 最简单的方式：
# stdio 本地 Server
claude mcp add github -- npx -y @modelcontextprotocol/server-github
# HTTP 远程 Server
claude mcp add --transport http notion https://mcp.notion.com/mcp
# SSE（已弃用，但仍可用）
claude mcp add --transport sse asana https://mcp.asana.com/sse
三种作用域的区别很重要：
Local 作用域（默认）：配置存储在 ~/.claude.json 中，按项目路径区分。只对你自己、在当前项目中生效。适合实验性质的配置或者包含敏感凭证的场景。
Project 作用域：配置存储在项目根目录的 .mcp.json 文件中。这个文件可以提交到 Git，团队成员都能共享。适合团队标准工具，比如共用的 Sentry 监控或者项目数据库。
User 作用域：配置存储在全局 ~/.claude.json 中，所有项目通用。适合你个人常用的工具，比如 Perplexity 搜索或者 Context7 文档查询。
作用域的优先级是 Local > Project > User。这意味着你可以在 .mcp.json 里放团队共享的 Server 配置，然后在本地用 Local 作用域覆盖认证凭证，保持 Server 名称一致的同时让密钥保持私有。
Claude Code 还有一个巧妙的能力：它可以同时当 MCP Client 和 MCP Server。运行 claude mcp serve，其他工具比如 Cursor 或者 Claude Desktop 就可以通过 MCP 协议调用 Claude Code 的内置工具（文件编辑、Bash 执行、搜索等）。
另外值得一提的是 Claude Code 的 Tool Search 功能。当你配置了很多 MCP Server 时，所有工具的定义会占用上下文窗口。Tool Search 会动态加载需要的工具，而不是一股脑全部塞进去，大幅减少上下文消耗。
OpenAI Codex CLI：TOML 格式，统一配置
OpenAI 的 Codex CLI 在 2025 年 9 月正式支持了 MCP，但它的配置方式和 Claude Code 有明显区别。
首先，Codex 使用 TOML 格式的配置文件，而不是 JSON。配置文件在 ~/.codex/config.toml，CLI 和 VS Code 扩展共享同一个配置文件。这意味着你只需要配置一次，两个客户端都能用。但也意味着一旦 TOML 语法出错，两个客户端会同时挂掉。
配置的写法像这样：
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"][mcp_servers.figma]
url = “https://mcp.figma.com/mcp” bearer_token_env_var = “FIGMA_OAUTH_TOKEN”
Codex 同样支持 stdio 和 Streamable HTTP 两种传输方式。命令行管理用 codex mcp add。有趣的一点是，Codex 自己也可以作为 MCP Server 运行（codex mcp-server），暴露 codex() 和 codex-reply() 两个工具，供其他 Agent 调用。
和 Claude Code 的三层作用域不同，Codex 的作用域相对简单：全局配置在 ~/.codex/config.toml，项目级配置在 .codex/config.toml（仅限受信任的项目）。
Codex 还有一些独有的配置选项，比如 enabled_tools 和 disabled_tools 白名单/黑名单、startup_timeout_sec 和 tool_timeout_sec 超时控制、以及 mcp_oauth_callback_port OAuth 回调端口设置。这些精细控制在 Claude Code 中需要通过环境变量或者其他方式间接实现。
VS Code (Copilot) 和 Cursor：配置大同小异
VS Code 和 Cursor 的 MCP 配置格式略有不同。
VS Code 的配置文件是 .vscode/mcp.json，格式是这样的：
{
"mcp": {
"servers": {
"server-name": {
"command": "npx",
"args": ["-y", "some-package"]
}
}
}
}
注意外层多了一个 "mcp" 包裹。
Cursor 的配置文件是 .cursor/mcp.json，格式和 Claude Desktop 更像：
{
"mcpServers": {
"server-name": {
"command": "npx",
"args": ["-y", "some-package"]
}
}
}
VS Code 有一个方便的功能：它可以自动发现其他工具已安装的 MCP Server，比如你在 Claude Desktop 里配置过的 Server。Cursor 则更直接，配置风格和 Claude 系的产品保持一致。
最关键的区别在于内部的 command、args、env 结构，这部分在所有工具中几乎完全一样。所以实际上，一旦你理解了一个 Server 的配置方式，切换到其他工具时只需要调整一下外层格式和配置文件路径就行。
远程 Server 的认证：OAuth 2.1
对于本地的 stdio Server，认证通常很简单——直接在环境变量里放 API Key 就行。但远程 Server 就不一样了，它需要一套正式的认证流程。
MCP 在 2025 年 3 月的协议更新中引入了标准的 OAuth 2.1 认证机制。在 2025 年 6 月的更新中，这套机制又做了重要的完善：MCP Server 被正式定义为 OAuth 的”资源服务器（Resource Server）”，而认证逻辑交给独立的”授权服务器（Authorization Server）”处理。
认证的大致流程是这样的：Client 首次连接远程 Server 时，Server 返回 401 未授权状态码，同时告诉 Client 到哪里去找授权信息（通过一个 Protected Resource Metadata 文档）。Client 拿到授权服务器的地址后，发起标准的 OAuth 授权码流程（强制使用 PKCE），获取 Access Token，然后在后续的请求中通过 Authorization 头部携带这个 Token。
对于 Claude Code 用户来说，认证远程 Server 可以通过 /mcp 命令交互式完成。Codex CLI 提供了 codex mcp login 命令来处理 OAuth 流程。
6 月的规范更新还引入了一个重要的安全措施：Resource Indicators（资源指示器）。它要求 Client 在请求 Token 时明确指定 Token 的目标 Server，防止一个恶意 Server 拿到的 Token 被滥用到其他服务上。
实战：配一个 GitHub MCP Server
说了这么多理论，来走一遍实际操作。以 GitHub MCP Server 为例，看看在不同工具中怎么配置。
Claude Code 里：
# 方法一：HTTP 远程（推荐）
claude mcp add --transport http github \
https://api.githubcopilot.com/mcp \
--header "Authorization: Bearer YOUR_TOKEN"
# 方法二：本地 Docker
claude mcp add github \
-e GITHUB_PERSONAL_ACCESS_TOKEN=ghp_xxxx \
-- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN \
ghcr.io/github/github-mcp-server
Codex CLI 里：
codex mcp add github -- docker run -i --rm \
-e GITHUB_PERSONAL_ACCESS_TOKEN \
ghcr.io/github/github-mcp-server
或者直接编辑 ~/.codex/config.toml：
[mcp_servers.github]
command = "docker"
args = ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"]
Claude Desktop 里：
编辑 claude_desktop_config.json：
{
"mcpServers": {
"github": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
"ghcr.io/github/github-mcp-server"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxx"
}
}
}
}
你会发现，核心的 Server 启动参数在所有工具中都是一样的，区别只在配置文件的格式和位置。
团队协作中的最佳实践
当 MCP 从个人工具变成团队基础设施时，有几个实践值得注意。
第一，善用 Project 作用域。在项目根目录的 .mcp.json 中定义团队共用的 Server，提交到 Git。比如 Sentry 错误监控、项目数据库连接、CI/CD 相关的工具。认证凭证通过环境变量引用，而不是直接写死：
{
"mcpServers": {
"sentry": {
"type": "http",
"url": "https://mcp.sentry.dev/mcp",
"headers": {
"Authorization": "Bearer ${SENTRY_AUTH_TOKEN}"
}
}
}
}
每个开发者在本地设置自己的 SENTRY_AUTH_TOKEN 环境变量，或者用 Local 作用域覆盖认证信息。
第二，注意上下文消耗。每个启用的 MCP Server 都会在上下文窗口中占用空间，因为 AI 需要知道每个工具的定义和用法。如果你配了十几个 Server，光工具定义就可能吃掉几万个 Token。Claude Code 的 Tool Search 功能可以缓解这个问题，但其他工具目前还没有类似的机制。建议只启用当前任务真正需要的 Server。
第三，Windows 用户的特殊注意事项。在原生 Windows（不是 WSL）上使用 npx 启动的 MCP Server 时，需要加上 cmd /c 前缀。否则 Windows 无法直接执行 npx，会报”连接已关闭”的错误。
写在最后
MCP 的出现是 AI 工具生态中的一个重要里程碑。它做的事情看起来不性感——无非就是定义了一套通信协议——但正是这种”无聊”的标准化工作，让整个生态能够快速生长。
从协议层面看，Streamable HTTP 取代 SSE 成为远程传输的标准，OAuth 2.1 成为认证的基础，这些都在往更成熟、更安全的方向演进。从工具层面看，Claude Code 的三层作用域设计和 Tool Search 机制展示了很好的工程思考，Codex 的 TOML 统一配置则体现了另一种简洁的设计哲学。
对于开发者来说，好消息是学习成本没有看起来那么高。核心的 Server 配置模式在所有工具中几乎一样，差别只在外层的包装格式。掌握了 stdio 和 Streamable HTTP 两种传输方式、理解了作用域和认证机制，你就能在任何 MCP Client 中游刃有余了。
MCP 的协议仍然在快速演进中——2025 年 3 月和 6 月两次大的规范更新就足以说明这一点。如果你在生产环境中依赖 MCP，记得持续关注协议变更。但总体的方向是清晰的：AI 工具的能力边界正在被打开，而 MCP 就是那把钥匙。
发表回复