不吃章鱼烧MCP 这个词，过去一年几乎把我身边所有 AI 工具的接入方式都重写了一遍。全称 Model Context Protocol，模型上下文协议，简单说就是给 AI 应用和外部工具之间定了一套标准接口，让"AI 主动去查数据库、操作浏览器、读设计稿"这种事情不再依赖某个厂商的私有插件体系。我的日常 workflow 也因为这个东西发生了明显变化：以前是把代码复制粘贴给 AI 看，现在是让 AI 自己连上仓库、连上数据库、连上测试环境去干活。这篇笔记不是官方文档的复述，而是我几个月里从零搭 MCP Server、接各种现成 MCP 工具、在 Cursor 和 Claude Code 之间反复切换排查问题的一条完整记录。如果你正在纠结 MCP 到底是什么、要不要自己写一个 server、以及怎么把它接进自己的工具链，这篇应该能省下你不少试错时间。
1. 先搞明白MCP到底在解决什么问题
1.1 从"AI只能聊天"到"AI能动手干活"的转折点
最早用 AI 编程时，我的工作流很原始：把报错信息贴给 AI，它给我一段修复建议，然后我手动去改。后来有了 Copilot 这种能直接读当前文件的工具，体验好了一些，但也就止步于"读文件"和"补代码"。真正的转折是我第一次让 Claude 自己去查数据库——它通过 MCP 连上 MySQL，执行了几条 SELECT，根据真实数据定位了问题根因，而不是对着我贴过去的几行日志瞎猜。
这件事背后就是 MCP 的核心价值：它把"AI 能访问什么数据、能操作什么工具"从模型能力中解耦出来。模型不需要预先训练过某个工具怎么用，只要工具按照 MCP 协议暴露出来，模型就能通过 tool call 发现它、理解它、调用它。
说到这里必须澄清一个常见误区：MCP 不是"某个 AI 模型的能力"，而是一种应用层协议。就像 HTTP 定义了浏览器和服务器怎么通信，MCP 定义的是 AI 应用（Host）和能力提供方（Server）之间怎么通信。这意味着理论上任何 AI 应用都能接入任何 MCP Server，这也是它能在 Cursor、Claude Code、Trae、Cherry Studio、Codex 这些不同客户端里通吃的根本原因。
1.2 角色拆解：Host、Client、Server、Tool
MCP 的架构里有几个角色，我第一次看文档时被绕晕了，这里用人话捋一遍：
- Host：跑着 AI 模型的那个应用，比如 Claude Desktop、Cursor、VS Code 里的 Cline。它负责和用户交互，决定什么时候调用工具。
- Client：Host 内部的协议客户端，负责和 Server 建立连接、收发协议消息。一个 Host 可以同时连接多个 Client。
- Server：能力提供方，暴露出一组 tool（工具）、resource（资源）、prompt（提示模板）。它可以是本地进程，也可以是远程服务。
- Tool：Server 暴露给模型的具体操作，比如"查询用户表""创建工单""打开浏览器访问 URL"。每个 Tool 都有名字、描述、输入参数的 JSON Schema，模型根据这些信息决定怎么调用。
打个比方：Host 是个项目经理，MCP Server 是个工具箱，Tool 是箱子里的一把把工具。项目经理（模型）不需要知道扳手的内部结构，只需要看工具标签（描述和 Schema）就知道该怎么用它。
这套设计最聪明的地方在于标准化。在没有 MCP 之前，每个 AI 工具都搞自己的一套插件 API，Cursor 插件没法给 Claude Desktop 用，Claude 的 skill 又绑死在自家生态里。MCP 把这三件事统一了：协议是公开的，Server 是独立的，任何 Host 都能接。
1.3 和Function Calling、Computer Use、Skills的边界
这是我在社区里被问得最多的问题，三个名词经常被混在一起。
Function Calling 是模型能力层面的事，指的是模型根据用户输入输出一个结构化调用请求，比如 {"name": "get_weather", "arguments": {"city": "北京"}}，是模型和调用方（也就是 Host）之间的约定。MCP 是应用架构层面的事，它解决的是 Host 怎么找到外部工具并调用它。换句话说，Function Calling 是"模型怎么开口"，MCP 是"工具怎么被递到模型手上"。
Computer Use（比如 OpenAI 的 Operator）走的是另一个极端：不依赖 API，直接截屏、模拟鼠标键盘操作界面。它的好处是能操纵没有 API 的遗留系统，代价是慢、容易错、每一步都需要视觉判断。MCP 这种结构化工具调用则是直接走接口，快、稳、可控。两者互补：有 API 的场景优先用 MCP，只能靠 UI 操作的老系统才考虑 Computer Use。
Skills 在 Claude 的语境里更像是"能力说明书"——一段 markdown 文档，教模型做事的规则、步骤、经验，比如"写 Python 前先看项目里的 requirements.txt"。Skill 本身不执行操作，但它可以指示模型去调用 MCP Tool。所以正确的关系是：Skill 是大脑里的操作手册，MCP Tool 是手上的工具，两者配合使用。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从零搭一个MCP Server：最小实现里最关键的几个决定
2.1 SDK选型：Python FastMCP和TypeScript SDK怎么挑
如果你搜"MCP Server 开发"，官方推荐的是 TypeScript SDK 和 Python SDK。我两个都用过，说下真实体感。
TypeScript SDK（@modelcontextprotocol/sdk）生态最完整、文档最多，适合你本来就在 Node 技术栈里、或者 Server 要集成到前端/Electron 工具里。Python 这边有个宝藏库叫 FastMCP，把 SDK 封装成了类似 FastAPI 的装饰器风格，写起来异常舒服，适合快速做原型和内部工具。
我的建议很直接：做一次性内部工具、追求快速迭代，选 Python FastMCP；要做成发布出去给别人用的正经 Server，选 TypeScript SDK。理由有两个：一是 TypeScript SDK 对 Streamable HTTP 和 OAuth 的支持更完善，这在后面