选 MCP 服务器不要先看数量，先看它暴露的是 tools 、 resources 还是 prompts，再确认它的权限边界能不能收窄。多数团队踩的坑都出在这里：接了一堆服务器，模型可用工具暴涨到上百个，选错工具的概率和上下文占用一起上升，而其中真正用到的不超过十个。
第一步：分清三种能力，别混着挑
MCP 服务器对外只提供三类能力，性质完全不同：
- Tools（工具）：模型可以调用的函数，会产生副作用。这是绝大多数服务器提供的主要能力。
- Resources（资源）：可被读取的数据，通过 URI 暴露，有的还支持订阅。适合放文档、 schema 、配置这类”被读”的内容，比做成工具更省上下文。
- Prompts（提示模板）：预置的可复用流程，由用户或客户端触发，不是模型自动调用。
挑服务器时先问一句”我需要的是让它做事，还是让它给数据”。做事要 tools，给数据优先看 resources——后者对上下文友好得多，也更容易做缓存。
第二步：按用途分层，而不是平铺接入
官方参考实现大致可以分成四类，接入优先级也不同：
| 类别 | 典型服务器 | 接入优先级 | 注意点 |
|---|---|---|---|
| 数据与文件 | Filesystem 、 SQLite 、 PostgreSQL | 最先接，收益最直接 | Filesystem 必须限定允许目录；数据库优先用只读模式 |
| 开发工具 | Git 、 GitHub 、 GitLab | 高，工程场景刚需 | 写操作要单独确认，令牌用最小权限 |
| 检索与浏览 | Fetch 、 Brave Search 、浏览器自动化 | 中，按需接 | 会触达外部世界，必须配域名白名单与超时 |
| 业务与协作 | Slack 、 Linear 、 Google Maps 等 | 低，确认有真实需求再接 | 涉及真实业务数据，先定权限边界再接 |
官方维护的实现和社区实现的可靠性差距很大。社区服务器没有经过验证，接之前至少要看三件事：最近有没有更新、开源协议、以及它是否需要过宽的权限（一上来就要管理员令牌的，先放一放）。
第三步：看工具本身的质量，而不只是功能清单
同样是”能查数据库”，工具写得好的和写得差的，模型调用成功率能差出一倍。检查清单：
- description 一句话说清何时用，并且写明不覆盖什么、该用哪个兄弟工具。这条能让模型少走很多试错调用。
- inputSchema 有约束：枚举代替自由字符串、有 minLength / maximum / format 、必填项标清楚、
additionalProperties: false。 - 有 annotations：
readOnlyHint、destructiveHint、idempotentHint、openWorldHint这四个提示决定客户端是否要弹确认。破坏性操作在工具名里就要看出来。 - 返回体小而稳定：只回 ID 、摘要与分页游标，大内容给 URI 让调用方按需取。
- 错误可恢复：业务错误用
isError: true返回可读文本，协议错误走标准 JSON-RPC 错误码，并且指明是哪个字段出的问题。
annotations 说谎比不写更危险
第四步：定接入顺序，一次只加一个
并发接五个服务器之后出问题，你没法判断是谁的锅。推荐顺序：
- 先接一个只读的、本地的（如 Filesystem 限定到单个目录），跑通整条链路。
- 再加一个带写能力的，观察确认流程是否顺畅、误操作是否拦得住。
- 最后接触达外部网络的（Fetch 等），配域名白名单、超时与调用频率限制。
- 每加一个都回头看一次：工具总数、平均调用成功率、单次会话的 token 消耗。
接入位置也有讲究，配置放在哪一层决定了谁能共享、会不会把密钥带进仓库，详见 MCP 配置放哪一层。多服务器编排时的命名冲突与成本问题见 一个客户端接多个 MCP Server。
第五步：什么时候必须自建
有四种情况，现成的服务器救不了你：
- 内部系统：没有公开实现，只能自己包一层。
- 权限需要按调用者区分：公共服务器通常是一个凭据走天下，要做租户级隔离就必须自己控制。
- 工具集需要裁剪到极小：把内部几十个接口全暴露成工具是最常见的错误做法，正确做法是挑出三五个高频动作单独包装。
- 要返回结构化数据：让调用方直接消费类型化的输出，而不是重新解析 Markdown 文本，需要自己定义输出 schema 。
自建时如果已有 REST API，优先走自动转换而不是重写，取舍见 把现有 REST API 包装成 MCP Server。写完之后怎么测、怎么发，分别看 MCP 服务器怎么测试 和 MCP 服务器怎么发布分发。
- 确认能力类型：要的是做事（tools）还是给数据（resources），据此筛掉一半候选。
- 看工具集规模：超过二十个工具的先看能不能裁剪，不能裁剪就换一个或自己包一层。
- 检查 description 、 inputSchema 约束、 annotations 与返回体大小四项，任一项缺失就当作质量不合格。
- 定权限边界：限定目录或作用域、只读优先、凭据用最小权限，并确认它不要求过宽授权。
- 单独接入并观察一轮：记录调用成功率与 token 消耗，确认没问题再加下一个。
别忘了安全这一层
接入之后的常见风险有三类：提示注入（外部内容里藏指令诱使模型调用写操作）、凭据泄露（令牌进了上下文或配置仓库）、越权（工具能用但权限没收窄）。前两类在 MCP 安全风险怎么防 里有完整清单，凭据的正确放法见 MCP 服务器凭据怎么管。
另外一点：能力是协商出来的，不是服务器单方面声明的。客户端和服务器在建立连接时会交换各自支持什么，版本对不上或能力没对齐是”接上了但工具一个都不出现”的第一大原因，相关机制见 MCP 能力协商与版本兼容。
工具越多模型越强吗
社区服务器能直接用吗
为什么服务器接上了但模型看不到工具
同一个需求，用工具还是用资源
小结
选 MCP 服务器本质上是在做减法：先按能力类型筛，再按工具集规模裁，然后定权限边界，最后逐个接入观察。接得越少、每个越精，模型反而越强。真找不到合适的就自己包一层——只暴露三五个高频动作的小服务器，往往比大而全的现成实现好用得多。
评论 (0)