呱呱 创新方案
造 MCP server / 给 AI 加工具：工具设计决定成败
给 AI 做工具（MCP server 或自建工具）时，决定质量的是工具本身好不好用，不是功能全不全。命名可发现、描述写清「何时触发」、错误信息带解法、返回聚焦数据。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
适用场景
MCPMCP server给AI加工具工具开发tool callingfunction call
解决思路
- 命名要可发现：用一致前缀 + 动词开头（github_create_issue / github_list_repos），让模型一眼找得到
- 描述必须写清「什么情况下该调它」，而不是只描述它做什么——模型靠这句决定要不要调
- 错误信息要可操作：不只报错，给具体建议和下一步（这直接决定模型能不能自己修好）
- 返回要聚焦：支持分页/过滤，别一次糊一大堆数据进上下文（每多一个字段都是上下文成本）
- 优先覆盖完整 API 端点（给模型组合的自由），而非只做几个高层工作流工具——除非某类任务确实需要专门封装
- 本地服务用 stdio，远程用 Streamable HTTP + 无状态 JSON（更好扩、更好维护）
适用边界 · 注意事项
- 别把工具描述写成功能说明书 —— 模型关心「什么时候用」胜过「它内部怎么实现」
- 别让工具返回超大无过滤结果，会挤爆上下文
- 别新增核心工具来解决本来 CLI+skill 就能做的事（每个工具都要在每次 API 调用里付费）
完整经验
问题：给 AI 加工具（MCP server 或平台自建工具）时，容易专注在「功能实现了吗」，但上线后发现 AI 该用的时候不用、用了又用错。
根因：决定这类工具质量的不是功能覆盖，而是工具对模型的可发现性和可操作性。
解决：五个设计要点。
① 命名可发现：一致前缀 + 动词开头（如 github_create_issue、github_list_repos）。
② 描述写清「何时触发」：模型靠描述这句决定要不要调用。只写"这个工具能做什么"不够，要写"什么情况下该用它"。
③ 错误信息可操作：不只报错，给具体建议和下一步——模型能不能自己修好，全看这里。
④ 返回聚焦：支持分页/过滤，别一次糊一大堆数据进上下文（每个字段都是每轮对话的固定成本）。
⑤ 优先覆盖完整 API 端点，给模型自由组合的空间；除非某类任务确实需要专门封装成高层工作流。
传输方式：本地服务用 stdio，远程用 Streamable HTTP + 无状态 JSON。
推论：不是所有能力都值得做成工具。每个工具都在每次 API 调用中付费，所以先用 CLI+skill 或插件解决，确实需要再上工具。