精通之路：MCP 生态与选型决策
纵览 MCP 工具生态与协议演进，掌握"何时用 MCP、何时原生集成"的决策框架，完成毕业项目规划。
生态地图
- 官方参考 Server：文件系统、Git/GitHub、Slack、Google Drive、Playwright 浏览器、SQLite/Postgres…
- 社区 Server：数千个，覆盖主流 SaaS 与内部系统；挑选时看维护活跃度与来源可信度；
- 注册中心：MCP Registry 等目录服务正在兴起，未来"发现工具"会像装 App 一样简单。
决策框架：什么时候用 MCP，什么时候不用
| 场景 | 建议 |
|---|---|
| 希望被多个 AI 应用复用的通用能力 | ✅ 做 MCP Server（一次实现处处可用） |
| 使用社区现成的成熟集成 | ✅ 直接装 MCP Server |
| 单一应用内部的固定工具 | ❌ 原生 Tool Calling 更简单（少一层进程与协议开销） |
| 极低延迟要求的内联工具 | ❌ 原生集成（stdio 也有进程管理成本） |
记忆口诀：跨应用共享用 MCP，应用内自用走原生。
毕业项目规划：个人 AI 助手的统一工具层
- 写一个 MCP Server 封装你最常用的 3 项能力（如课程库查询、待办管理、笔记搜索）；
- 同时接入 Claude Desktop 与你的 LangGraph Agent（用适配器），验证"一次实现、处处使用"；
- 加上 Roots 限权与调用审计，按本模块安全清单自查；
- 把 Server 发布给团队 —— 你已经从 MCP 使用者成长为提供者。
协议仍在演进
MCP 版本迭代很快（传输层从 SSE 演进到 Streamable HTTP、新增 Elicitation 等）。跟着官方文档走，但核心心智模型（三角色、三原语、控制权归属）非常稳定 —— 这正是你已掌握的部分。
至此 MCP 模块毕业。工具接入的碎片化时代正在结束，而你已经站在标准化这一边。
📝 课后练习
quiz-1 哪种场景不建议使用 MCP，而应走原生 Tool Calling？