技术 · 熟练
你写的 MCP，为什么同事装不起来？
接得上 ≠ 分得出去
自己电脑上跑得好好的 MCP server，发给同事就卡在「这段 JSON 粘到哪」——这不是他笨，是你交付的是一份说明书，不是一个能装的东西。2026-10 起这条路被修直了：新的 MCPB 打包格式，把本地 MCP server 与一份 manifest 打成一个 zip，对方双击、拖进窗口，或从设置里选一下，就装完了 —— 不用写安装脚本，不用一步步念配置。怎么做：先分清「本地跑」与「远端接」两条路 → 把本地的那个打成包 → 在 manifest 里把工具清单与权限写清楚 → 发一个 zip 出去。⚠️ 打包不是压缩：manifest 写漏一项，装上去就少一个工具，而对方只会说「这东西不好用」。
方法 · 一图看懂
1
先分路：本地跑还是远端接 — 本机读文件 / 跑命令 / 要临时目录的走本地；要认证 / 要共享 / 多人同时用的走远端
2
本地那个打成包 — 一个干净目录 + 一份 manifest.json，打成 zip 就是安装包，装与卸都交给客户端
3
manifest 里写清三件事 — 这个 server 叫什么、暴露哪些工具、需要客户端给什么权限
4
发布前换一台干净机器装一遍 — 看工具是不是一个不少、能不能真的调起来
5
给远端那条留出口 — 团队共用的仍走托管下发；打包只解决「本机私有工具」的分发
原理 · 为什么有效
为什么以前装一个 MCP 这么难，现在却可以双击 —— 差别不在协议，在「谁负责把依赖摆好」。MCP 本身只规定两端怎么说话，它没说一个本地 server 要带哪些运行环境、入口写在哪、缺依赖怎么办。于是每个作者写一份 README，而每台电脑环境不同：Node 版本不一样、路径不一样、Python 装没装不一样 —— 配置这件事被推给了最不专业的那一环：使用者。打包格式做的，是把这个责任从使用者手里收回到作者手里：作者把入口、依赖声明、工具清单、权限需求一次性写进 manifest，客户端照单安装。它把「一段需要人念的配置」变成了「一个程序能读懂、人也能双击的对象」。这也正是它值得单独讲一次的原因 —— 凡是要交给别人用的工具，卡点从来不在功能，而在交付形态。
适用场景
适合：自己写了本机 MCP server、想发给同事或发到社区的人；工具散落各处、每次换电脑都要重配一遍的人；正在评估「这个工具要不要做成 MCP」的人。不适合：只在自己一台机器上用、从没打算分发的人 —— 多打一个包只是多一层维护；也不适合需要服务端认证与企业统一策略的团队场景，那条路归「托管下发」（组织一次配好、全员生效），不是打包覆盖的范围。
自测 · 4 问
我这个 server 是不是只在我这一台机器上跑过？没在干净环境装过，就别发
manifest 里的工具清单，和 server 实际暴露的，是不是一个不少？
它要求客户端给的权限，我是不是逐条读过（读写文件 / 执行命令 / 访问网络）？
卸载这条路我走过没有 —— 装得进去但卸不干净，是分发工具最常见的后账
怎么上手 · 验证步骤
上手顺序：先在本机跑通，再把它变成一个包，最后才发给别人。第一步，本机跑通 —— 别急着打包，先用客户端连上一次，确认工具都能被调起来。第二步，准备一个干净目录：入口脚本、依赖声明、一份 manifest.json。第三步，把「叫什么、有哪些工具、要什么权限」写进 manifest —— 这是全包里最值钱的一份，写得越具体，对方越不用问你。第四步，打成 zip。第五步，换一台没装过任何相关环境的机器装一遍：这一步会替你把九成问题提前暴露出来。
装完当场做三件事：① 在客户端里列出这个 server 暴露的工具，逐个点开看一遍，数一数与 manifest 是否一致；② 随便调一个工具跑一次，确认不是「列得出来但调不动」；③ 走到扩展 / 插件列表里，确认它有卸载入口 —— 装得上、看得到、卸得掉，三样齐了才算这个包合格。