功能对比
| 来源类型 | 适合用途 | 安装前审查 |
|---|---|---|
| 官方文档或 registry | 已知 server 名称、支持的设置路径、兼容说明 | 版本、所需凭证和精确命令 |
| 工具 marketplace | Claude Code、Cursor 或 IDE 专属安装流程 | 该 server 是否能脱离该工具使用 |
| Awesome list | 广泛发现和社区项目 | 维护状态、package 归属和 issue 活跃度 |
| GitHub repo | 源码审查和高级设置 | License、releases、安全说明和安装脚本 |
| 内部 catalog | 团队批准的 servers 和私有工具 | 负责人、访问范围、审计期待和轮换步骤 |
Marketplace 评估清单
从任何 MCP marketplace 或目录安装 server 前，先审查 package、权限模型和运维负责人。
[ ] Server 能读什么数据？ [ ] 它能写入、删除或执行动作吗？ [ ] 谁维护这个 package？ [ ] 凭证存在哪里？ [ ] 哪些工具支持这个配置？ [ ] 失败时 fallback 是什么？
Marketplace 与 Directory
Marketplace 通常强调工具内安装和发现。Directory 或 awesome list 更适合在采用某个 server 前比较类别、替代方案和设置取舍。
推荐团队流程
用公开 catalog 做发现，用窄配置本地测试，再把批准的 servers 提升到内部 catalog。
- 从 marketplaces、官方文档和 curated lists 发现候选项。
- 生成小型 mcp.json，每次只测试一个 server。
- 记录负责人、scope、安装命令和凭证处理方式。
- 工具、package 或 token scope 变化时审查 catalog。
常见问题
有唯一官方 MCP marketplace 吗？
MCP 发现分散在官方文档、工具专属 catalog、GitHub repos 和 curated lists 中。把每个来源都当作发现入口，再自行验证 server。
可以直接从 marketplace 安装 servers 吗？
只有在审查命令、权限、凭证和维护状态后才建议安装。团队场景应把批准选项提升到内部文档。
第一个 MCP server 选什么？
编码工作流里，filesystem 或 GitHub 常见作为第一选择，因为它们对应重复的项目上下文任务。
什么时候应该自建 MCP server？
当私有 API、内部工作流或产品专属上下文没有被现有维护良好的 server 覆盖时。