🎯 核心主张（一句话）
MCP 是 AI 工具集成的 USB-C：用一套标准协议把「每对组合单独写适配器」的 M×N 难题压成 M+N，但它只解决「能连上」，不解决「用得好」——后者要靠 Skills，且工具越多不等于越强。
📖 正文
它解决什么：集成爆炸
MCP 出现前，AI 客户端和数据源之间的每条连接都要单独搭桥：GitHub 接 Claude 写一个适配器，接 ChatGPT 再写一个。5 个客户端 × 100 个数据源 = 500 个适配器，每新增一方，成本线性放大。
MCP（Model Context Protocol）的解法和 USB-C 一样：客户端实现一次 MCP 客户端协议，数据源实现一次 MCP 服务器协议，任意互通。500 次开发降到 105 次（5+100）。
这个标准赢的速度说明了痛点有多真：2024 年 11 月 Anthropic 开源，4 个月后 OpenAI 采纳，2025 年 12 月捐给 Linux 基金会旗下的 AAIF，成员包括 OpenAI、Google、Microsoft、AWS。13 个月，从一家公司的项目变成行业公共基础设施。
怎么运作：客户端-服务器 + JSON-RPC
架构直接借鉴了 VS Code 的 LSP（设计者 David Soria Parra 承认过这一点）：Host（Claude Code 等宿主应用）内置 MCP 客户端，负责发现服务器能力、构造调用、处理响应；MCP 服务器是独立程序，连着数据库/API/文件系统，把能力暴露给客户端。通信走 JSON-RPC 2.0。
传输方式记一条准则就够：本地用 stdio，远程用 HTTP。stdio 由客户端以子进程方式启动服务器，走标准输入输出，不需要网络，延迟最低也最安全；HTTP 用于远端服务（公司内网 Jira、SaaS 接入点），支持 OAuth 2.0。SSE 已废弃，见到就迁移。
服务器暴露三类原语：
| 原语 | 是什么 | 例子 |
|---|---|---|
| Tools | 供 Claude 主动调用的函数，有副作用 | 建 Jira 工单、发 Slack 消息 |
| Resources | 只读数据，类似"文件" | 读 README 内容 |
| Prompts | 可复用的提示词模板，标准化任务启动 | code-review 模板 |
实践中 Tools 覆盖了绝大多数场景；Prompts 与 Skills 功能重叠，普及度最低。
怎么配：CLI、.mcp.json、作用域
claude mcp add 命令本质上是在操作 .mcp.json：
claude mcp add filesystem npx -y @modelcontextprotocol/server-filesystem /workspace
claude mcp add --transport http company-jira https://jira.company.com/mcp
claude mcp add --scope user github -- npx -y @modelcontextprotocol/server-github
.mcp.json 里最重要的机制是环境变量替换——${JIRA_TOKEN} 运行时才取值，${VAR:-default} 提供默认值。密钥放环境变量，配置文件只放引用，这样 .mcp.json 可以放心提交 Git 与团队共享。
作用域三层：项目根目录的 .mcp.json 是项目级（随仓库共享）；~/.claude/ 下是用户级（所有项目生效）；不宜入库的个人凭证放 .claude/settings.local.json（已被 gitignore）。企业还可以用 managed-mcp.json 集中预配置、预授权，全员零配置接入。
MCP 与 Skills：厨房与菜谱
Anthropic 官方的类比说清了分工：MCP 是专业厨房——冰箱（数据库）、炉灶（API）、刀具（工具）都有了，但每个厨师进来都得自己摸索怎么用；Skills 是标准菜谱——步骤、火候、时长写死，新手也能稳定出品，但没厨房就是空谈。
组合方式：在 SKILL.md 里引用 MCP 工具，让 Claude 按固定工作流调用它们。MCP 给能力，Skills 给用法，缺一边都不稳定。
放到全书框架里对照：Hooks 划禁区，Skills 定策略，MCP 扩边界——三者各管一层。
工具不是越多越好
每个 MCP 工具的名称和描述都要占上下文预算，工具太多会稀释 Claude 的选择准确率，还会拖慢响应。Claude Code 对 MCP 输出也有硬限制：超 10,000 Token 警告，超 25,000 Token 截断（MAX_MCP_OUTPUT_TOKENS 可调）——一条没加 LIMIT 的 SQL 就能把上下文冲垮。
选型纪律：只装当前工作流确实需要的服务器，定期用 claude mcp list 盘点，用不到的删掉。 另外先想想是否真的需要 MCP——很多"查文档""跑脚本"类需求，一个带脚本的 Skill 更便宜。
安全：信任边界在哪
MCP 让 Claude 能直接操作外部系统，风险随能力一起放大。三层防御：首次连接强制交互审批（无法绕过）→ 有副作用的工具调用二次确认 → 远程服务器用 OAuth 2.0 而非长期静态密钥。
三类已知攻击面：
- 提示注入：服务器返回的数据里可以夹带"忽略之前所有指令"这类恶意内容，污染 Claude 上下文。
- 权限组合滥用：单个工具看着无害，"读文件 + 发邮件"组合起来就是数据外泄通道。
- 冒名顶替：恶意工具伪装成合法工具的名称与描述诱导调用。
评估第三方 MCP 服务器和评估 npm 包是一回事：看来源（官方命名空间还是个人）、维护活跃度、下载量、口碑。数据库一律只读账号，密钥一律环境变量注入。
🧭 业界视角（书外补充）
- Simon Willison：直言 "Claude Skills are awesome, maybe a bigger deal than MCP"。他的理由是 Skills 有两个 MCP 给不了的性质——发现（Claude 自己判断何时加载，不常驻上下文）和确定性（脚本产出一致结果）。很多人用 MCP 做的事，一个带脚本的 Skill 更便宜、更稳。这与书中"厨房与菜谱"的框架一致，但立场更激进：默认先试 Skill，确实需要实时外部数据/操作外部系统时才上 MCP。
- Vercel 团队：删掉 80% 的 Agent 工具后，流程更精简、Token 更省、响应更快。这是"工具越多越好"直觉的直接反证——每个工具描述都在和别的工具争夺模型的注意力，工具列表是要主动做减法的资产，不是收藏夹。
- Anthropic 官方上下文工程指南：上下文是稀缺资源，性能随填充度衰减。MCP 工具定义常驻上下文这一点，正是它相对 Skills（渐进披露）的结构性劣势，装服务器之前先算这笔账。
🔗 知识网络
- upstream：Claude Code 四层架构与 Agentic Loop
- downstream：ClaudePlugins：能力的标准化分发、ClaudeHeadless 模式与 CI-CD 集成
- 平行关联：Skills：渐进式披露的知识包、Hooks：给概率模型上确定性缰绳、Claude Code 成本与安全工程