MCP 是一个开放协议，解决「大模型怎么接外部数据和工具」这件事——以前每个应用接每个数据源都要写一遍适配，MCP 把它变成统一接口，做一次到处能用。它的官方规范仓库只有 9,460 星，同组织的 servers 仓库却有 91,313 星，差近十倍。这个数字本身就是答案：大家真正要的不是协议文本，是有没有现成东西能直接接上。这两个数是 2026-10-17 用 GitHub REST API 实拉的，搜索引擎前排的 83.1k、91.1k、91.3k 全是不同月份的缓存快照。
大家通常怎么做
第一次听到 MCP，多数人去找教程，照抄一段配置，把某个 server 挂进客户端，跑通就算学会。我自己最早也这样，写了一篇从装 MCP 到出第一份拆解报告的实操，那段路确实「跟装插件差不多」。
副作用是你会以为 MCP 就是配置文件里那几行 JSON，是某家客户端的一个功能，换个客户端就抓瞎。
另一类人反着来，先读 SDK 源码，从 Python SDK 一路看到 transport 实现。我走过一半，真正上手才发现，坑一个接一个——你读的是某一个实现，协议本身另有说法，两者对不上时分不清谁错了。
为什么这条路走不通
根子上是三件事被混成一件：协议规范、SDK、server。
规范在 modelcontextprotocol/modelcontextprotocol，当前版本 2026-07-28。它规定消息长什么样、怎么协商能力、怎么取消。SDK 是各语言实现，我一并拉了真实数据（2026-10-17，api.github.com）：python-sdk 24,595 星 / MIT / 最新 release v2.3.0（2026-10-02）；typescript-sdk 13,595 星 / v2.3.1（2026-10-05）；go-sdk 5,234、csharp-sdk 4,586、rust-sdk 4,023、java-sdk 3,739（MIT）；servers 91,313 星 / 11,796 fork。
看出问题了吗？最热门的 Python SDK 才 24,595 星，不到 servers 的四分之一。热度分布已经摆出答案：绝大多数人只需要别人写好的 server，不需要自己写。
第二个坑更隐蔽：2026-07-28 版规范和早期版本不是一回事。早期是「连接级会话 + initialize 握手，且允许服务端主动发 JSON-RPC 请求」。新版原文写得很硬——servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses。老教程里「服务端反过来问客户端」的写法在新版不成立。规范专门留了 Backward Compatibility 一节，要求双方探测对方的「年代」再决定是否回退。所以抄到一篇老教程，不是教程错，它对的是另一个版本。
换个思路
别当工具学，当接口契约读。契约只有四句：传输用 JSON-RPC 2.0 且必须 UTF-8；三种角色是 Host（LLM 应用）、Client（宿主里的连接器）、Server（提供上下文与能力）；Server 提供三类能力——Resources（上下文与数据）、Prompts（模板化消息与工作流）、Tools（给模型调用的函数）；Client 这边有一个 Elicitation，即服务端反过来向用户要补充信息。
这条我几乎没见过中文资料提。它跟前面「服务端不能主动发请求」不冲突，走的是另一条路，做多轮填表时比硬塞参数舒服得多。
官方还给了出处：设计受 Language Server Protocol 启发。想理解定位，就去想 LSP 当年干了什么——一个编辑器支持一门语言本来每个组合都要写一遍，LSP 之后做一次到处能用。MCP 在 AI 应用里是同一件事。
具体做法
真要接一个，按这个顺序走。
先确认版本。看官方规范站顶部是不是 2026-07-28，再对一眼 SDK release 时间。Python SDK 是 2026-10-02 的 v2.3.0，比规范新，能用；手上要是大半年前的 SDK，先升级。
再选传输。官方只绑两种：stdio 是客户端拉起子进程、用标准流传换行分隔的消息；Streamable HTTP 是每条消息一个 HTTP POST 打到同一端点，回包是 JSON 或请求级 SSE 流。官方原话 Protocol semantics are identical on every transport——协议语义在任何传输上都一样，别在这步纠结。本地自用选 stdio，跨机器选 Streamable HTTP。
然后用 Inspector 验，别用业务客户端验。modelcontextprotocol/inspector 是官方可视化测试工具，11,087 星。连一次就能看到能力协商结果和 tools 列表，比猜快得多。
最后才考虑自研。官方 servers 仓库 91,313 星不是虚的，另有社区驱动的 modelcontextprotocol/registry（Go，7,369 星）。
还有个容易漏的：扩展。2026-07-28 版列了几个可选扩展，均需双方支持并在初始化时协商——Tasks（长任务异步与轮询）、Skills over MCP（把结构化操作说明通过 MCP 分发）、MCP Apps（图表表单嵌进对话）。第二条跟站内 Skills 那条同源趋势是一回事，只是搬到协议层。
效果对比
三种投入，回报差很多：
- 直接用现成 server——成本是填一段配置，占九成场景。
- 用 SDK 自写——Python SDK v2.3.0 最成熟，但要自己处理传输、协商、取消。值不值取决于这能力是不是只有你有。
- 啃规范再动手——规范仓库才 9,460 星，除非你写 SDK 或排查兼容性，否则最不划算。
还有个边界必须说：Tools 等于任意代码执行。官方 Security and Trust & Safety 一节写得很直白——工具描述里的 annotations 应视为不可信，除非来自你信任的 server；调用任何工具前必须拿到用户明确同意。别因为「它只是个协议」就放松警惕。
运营侧同理。我见过同事看到数据异动就下结论，第二天发现是对方平台搞活动带来的正常流量，白写；所以我习惯先按拉最近 28 天、按点击量排序过一遍再动手。采集类工具走的都是正规渠道，实际使用须遵守目标平台规则与相关法律法规，别把「能连上」当成「可以随便用」。
常见问题
MCP 和 Function Calling 是一回事吗？
不是。Function Calling 是模型厂商提供的能力，MCP 是应用层协议。官方规范界定的范围是 Host、Client、Server 之间用 JSON-RPC 2.0 传消息，它不管模型怎么决定调哪个函数。
stdio 和 Streamable HTTP 选哪个？
本地自用、客户端能拉起子进程的选 stdio，最省事；要跨机器或多客户端共用选 Streamable HTTP。协议语义一样，后期换不亏。
为什么按老教程写的 server 连不上？
先对版本。2026-07-28 版明确 servers do not initiate JSON-RPC requests，早期版本允许服务端主动发请求。老教程对的是旧版，升级 SDK 或改写法二选一。
官方有没有能直接用的 server 清单？
有。modelcontextprotocol/servers（91,313 星）是官方参考实现集合，另有社区驱动的 modelcontextprotocol/registry（7,369 星）。
接第三方 server 要注意什么？
Tools 等于任意代码执行。官方要求调用前必须取得用户明确同意，工具描述里的 annotations 默认不可信。接之前先看一遍它的 tools 列表。
