目录
- 引子：300+ MCP Server 之后的警醒
- 问题盘点：为什么说 MCP 只是“注册协议”
- 痛点拆解：高维参数、一次性调用、质量失控
- 理想蓝图：LLM‑Native 的 MCP v1.0
- 可行升级路线：不用推倒重来
- 给开发者 & API 团队的行动清单
- 结语：补上三块板，MCP 仍有未来
1 引子：300+ Server 之后的警醒
微信公众号有文《唐霜：MCP就是个残次协议》说：过去一周，我们跑读了 mcp.so 上的 300 多个 MCP Server，并在本地逐一调试。结果令人沮丧：80 % 项目无法即插即用，参数缺失 …… “生态繁荣”背后是一地鸡毛。
关键结论
-
- MCP v0.4 本质只是 “工具注册 + 单次调用”，并未规定 LLM 如何吃到工具列表。
- 大多数 Server 直接把旧 SDK 套一层就丢上来，既不关心 LLM 可读性，也没有质量数据。
2 问题盘点
| 编号 | 痛点 | 现象 | 根因 |
|---|---|---|---|
| P1 | 与 LLM 交互缺失 | Client 只能自己把工具塞进 system prompt 或 tools |
规范层空缺 |
| P2 | 参数维度爆炸 | 十几个字段 × 多枚举 → LLM 只能走默认值 | API 先天面向人类程序员 |
| P3 | 只能“一问一答” | 复杂任务需轮番调用，协议无 session 概念 | 设计定位过窄 |
| P4 | 生态噪声 | Hello‑World Server 淹没优质工具，严重良莠不齐 | 缺质量信号 |
| P5 | 鉴权混乱 | OAuth/API‑Key/JWT 各玩各的 | 无统一枚举 |
3 痛点深拆
3.1 高维参数
LLM 既没足够 token 也没上下文去穷举组合，只能"默认值+玄学" → 结果鸡肋。
解决思路：把参数分层 ➜ required / recommended / optional，再允许工具在运行期追问缺失字段。
3.2 一次性调用
没有 session_id 就无法 patch 参数、串联多步。复杂工作流只能由客户端手写循环，重复烧 token。
3.3 质量与安全
没有健康检查、成功率、延迟数据；用户踩雷成本高。企业合规也缺统一 auth 描述。
4 理想蓝图：LLM‑Native MCP v1.0
| 模块 | 设计要点 | 价值 |
|---|---|---|
| 参数优先级 | priority 字段 + 示例 |
LLM 先填关键字段，省 token |
| 增量调用 | session_id + patch/cancel verb |
支持多轮计划，工具可追问 |
| 质量元数据 | qos.uptime / latency / success_rate |
注册表可排序过滤，劣币出局 |
| 统一鉴权 | `auth.type = oauth2 | x-api-key |
5 可行升级路线
-
- 合并
priorityPR；reference client 忽略未知字段即可兼容。 - 实验
session_id+patch。 - mcp.so 跑
mcp-lint，上线“质量徽章”。 - 发布 v1.0，留一年迁移窗口。
- 合并
6 行动清单
对 MCP Server 作者
-
- 标注
priority，附两组示例，跑 mcp-lint ≥80 分。 - 实现基本校验：枚举、range、类型。
- 输出
qos指标，申请绿色徽章。
- 标注
对 客户端 / Agent 框架
-
- 根据
priority裁剪 prompt；未知字段触发反问。 - 监控真实调用失败模式，定期更新校验器或微调补丁。
- 根据
对 API / SDK 团队
-
- Day‑1 就写 LLM‑Native 字段名（含单位）。
- 把默认值当“推荐”非“唯一”。
- 错误信息教学化：
validation_error.missing="distance_km"。
7 结语
MCP 需要的不是“推倒重来”，而是补上 参数治理、迭代调用、质量信号 三块主板。只要社区与头部客户端携手完成 v1.0，MCP 依旧有望成为“大模型用工具的 USB 插座”。
【相关】
