Claude 插件开放提交：你的 MCP 别再只躺在本地了

MCP 可以先理解成“让模型安全调用外部工具和数据的一套接口”；Skill 则更像“把一类任务的做法、脚本和说明打包给模型”。以前你可能把它们当作本地增强包，现在 Claude 给了一个更正式的出口：插件。

这次更新到底新在哪

Anthropic 官方博客说，开发者现在可以通过新的 directory submission portal 提交 Claude 插件，并在审核过程中查看状态、反馈和安全扫描结果。插件可以有两种提交方式：一种是单个远程 MCP connector，另一种是托管在 GitHub 上的 plugin bundle，把 MCP servers 和 skills 组合起来。

这句话翻译成人话：如果你做的是一个“让 Claude 连上某个系统”的能力，可以先走 MCP；如果你做的是一套完整工作法，比如拉数据、分析、生成报告、回写系统，那就更像插件包。

我更看重后半段：插件上线后，开发者还能看到安装、版本和搜索相关的使用数据。以前一个内部工具好不好用，经常靠群里一句“有人在用吗”；现在至少有机会看见它在哪个 Claude 产品里被装了多少次。别小看这个差别，很多工具不是死于功能差，而是死于没人知道它在哪儿。

先别把所有东西都打成插件

这里最容易误判的是：一听“目录提交”，就想把手头所有脚本都包装一遍。我的建议反过来，先挑一个最小但清楚的场景。

适合先做插件的东西，通常有三个特征：

举个小例子：把“读取 CRM 机会列表，生成本周跟进摘要”做成插件，比“让 Claude 帮销售变强”靠谱得多。前者有入口、有数据、有结果；后者听起来很燃，落地时经常只剩一屋子需求评审味儿。

一个下午能跑通的插件准备法

如果我今天要把一个自用 MCP 或 Skill 改造成可提交的 Claude 插件，会按这个 5 步走：

这个清单不华丽，但很抗摔。目录提交会有自动校验和安全扫描，越早把权限、输入输出、失败场景写清楚，越少在审核反馈里来回补作业。

对团队来说，真正要改的是交付习惯

这次 Claude 插件目录的意义，不只是给开发者多一个发布入口。它会慢慢改变团队内部 AI 工具的交付习惯。

以前大家常见的做法是：一个人把 prompt、脚本、MCP 配好，发到群里，其他人照着装。问题是版本散、权限散、说明散，过两周谁也不敢确认“现在大家用的是不是同一个东西”。

插件化以后，更合理的做法是把工具当成一个小产品来维护：有版本，有说明，有审核，有安装入口，有基础使用数据。尤其是面向 Claude Code 的插件，官方还提到可以包含 LSP、commands、hooks 和 agents，这就不只是聊天窗口扩展，而是能进入开发工作台的工具包。

我会把它看成一个信号：AI 工具从“会折腾的人自己配”走向“团队可以分发和治理”。这一步不酷炫，但很实用。毕竟老板不太关心你本地配置有多优雅，他更关心新人电脑上能不能少报两个错。

今天可以先做一个小决定

如果你手上已经有 MCP、Skill 或一组 Claude Code 配置，今天不用急着提交目录。先问一个问题：它是“只有我会用的个人捷径”，还是“别人也会反复需要的工作入口”？

前者继续留在本地，很好；后者就值得整理成插件候选。先做最小版，先写清权限和验收，再考虑上目录。基于公开信息看，Claude 这次给出的 portal、扫描、审核、发布和分析能力，正好适合把这类工具从“散装经验”变成“可交付资产”。

我今天的判断很朴素：不要为了赶生态热闹做插件，要为了少讲十遍安装说明做插件。这个收益，工具作者和使用者都懂。

参考来源：