创新方案
造 MCP server / 给 AI…
给 AI 做工具(MCP server 或自建工具)时,决定质量的是工具本身好不好用,不是功能全不全。命名可发现、描述写清「何时触发」、错误信息带解法、返回聚焦数据。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 49/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 90/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 52/100 ×0.15
适用场景
MCPMCP server给AI加工具工具开发tool callingfunction call
解决思路
- 命名要可发现:用一致前缀 + 动词开头(github_create_issue / github_list_repos),让模型一眼找得到
- 描述必须写清「什么情况下该调它」,而不是只描述它做什么——模型靠这句决定要不要调
- 错误信息要可操作:不只报错,给具体建议和下一步(这直接决定模型能不能自己修好)
- 返回要聚焦:支持分页/过滤,别一次糊一大堆数据进上下文(每多一个字段都是上下文成本)
- 优先覆盖完整 API 端点(给模型组合的自由),而非只做几个高层工作流工具——除非某类任务确实需要专门封装
- 本地服务用 stdio,远程用 Streamable HTTP + 无状态 JSON(更好扩、更好维护)
适用边界 · 注意事项
- 别把工具描述写成功能说明书 —— 模型关心「什么时候用」胜过「它内部怎么实现」
- 别让工具返回超大无过滤结果,会挤爆上下文
- 别新增核心工具来解决本来 CLI+skill 就能做的事(每个工具都要在每次 API 调用里付费)