示例

MCP 与 Skill 市场

怎么分辨一个真正好用的 MCP 服务端或 Agent Skill，以及去哪里浏览一个会持续更新的目录。

为什么需要一个目录

装一个 MCP 服务端或 Agent Skill 很容易，挑对却不容易。现在大多数人的发现方式还是翻那种很长的 awesome 列表：一个上万 star 的项目旁边，可能就躺着一个两年前就没人维护的项目，而页面上没有任何信息能帮你区分。

一个有用的目录不只是列名字。它会给项目分类、保持元数据新鲜，并给你足够的上下文去判断这个服务端或 Skill 值不值得接进自己的 agent。

在把它接进客户端之前，先看四件事。

维护健康度最后一次提交是什么时候？issue 有没有人回？没人维护的服务端是安全负债，不是捷径。

社区采用度只看 star 是很弱的信号。要找出真实使用痕迹：fork、下游引用、第三方集成。

文档完整度它有没有说清楚工具 schema、需要什么凭据、失败时什么表现？你要是看不懂返回什么，模型也一样用不好。

权限边界它要的是只读权限还是完整写权限？最小权限应该在安装前就看得见，而不是装完才发现。

Skill 是以纯文件形式分发的，所以判断角度和服务端不一样。

描述是否清晰描述是 Agent 在激活前唯一能看到的东西。模糊就永远不加载，太宽泛就会在无关任务上乱触发。

激活边界它有没有写清楚什么时候该用、什么时候不该用？边界清晰比文档冗长重要得多。

可组合性它能不能和你现有工具并存而不冲突？一个假设自己独占整个流程的 Skill，很难被复用。

打包了什么资源脚本和参考资料只有在真正必要时才算加分。先确认它附带的自动化是你自己愿意跑的东西。

生态分布很不均匀：服务端一侧被开发工具类占了大头，Skill 一侧则集中在研究和代码评审。先了解这个形状，能避免你在错误的地方白找。

实际结论

如果你要找一个冷门场景的服务端，可选项通常很少，需要逐个仔细读；如果你要的是研究或代码评审类 Skill，选择余地会大得多。

每个目录的排序规则都不一样，你看到的排名只是某种近似，而不是结论。在信任一个名次之前，有三件事值得确认。

它到底在衡量什么

采用度、维护活跃度、单纯的热度，是三套不同的指标。按 star 排序的榜单，回答的是和按健康度排序完全不同的问题。

数据有多新

从源码仓库自动刷新的目录，反映的是项目当下状态；人工维护的列表会悄悄过期，然后一直推荐已经死掉的项目。

排序依据是否公开

如果一个榜单从不说自己是按什么排的，把它当成浏览的起点就好，别当成推荐结论。

MCP Markets 是我们合作运营的 MCP 服务端与 Agent Skill 目录。它目前收录了数千个服务端和 Skill，每小时从源码仓库刷新一次数据，并且是按社区采用度和维护健康度给服务端排序，而不是单纯看 star 数。

它的分类结构正好对应上面那张表：服务端一侧以开发工具为主，Skill 一侧以研究和代码评审为主。目录里也有按场景整理的榜单页，所以你可以直接从自己在用的客户端切入，不必从头翻起。

从这里开始

如果你只想要一个入口，打开 MCP Markets，选中你的客户端或分类，装之前先读一遍维护信号。

如果你在维护一个服务端或 Skill，被目录收录是最省成本的曝光方式之一——因为看到它的人，本来就在找你要做的东西。大多数目录都提供免费收录，要的是仓库链接，而不是付费位。

提交之前，先确认仓库有看得懂的描述、能跑通的安装说明，以及明确的权限需求。这三点既是目录的筛选标准，也是读者的筛选标准。