用途：discuss-mcp 是一个咨询型（advisory）技能，用于反思并改进 MCP 服务器。它与 /build-tools、/build-evals 这类执行生成工作流的构建型技能不同，采用对话方式，帮助开发者理解应改进什么、为什么改以及怎么改。
适用提问：当开发者询问“如何改进我的 MCP 服务器”“为什么我的 evals 慢/贵/失败”“该不该加组合工具或代理工具”“我缺哪些工具”“下一步该建什么”“我的工具设计得好吗”“如何降低 eval 成本/轮次”时使用。
三条改进路径：一、追踪优化（trace-optimization.md），针对 evals 慢、贵、失败，基于 trace 数据分析性能并迭代改进工具；信号包括提到 evals、traces、成本、轮次、token、性能、LLM 挣扎、重复调用工具、选错工具。二、链式工具设计（chained-tools.md），讨论是否添加委派到其他 MCP 服务器的工具，以及用代理还是组合；信号包括 chaining、proxy、composite、multi-server、delegation、orchestration、多来源数据合并。三、行为分析（behavioral-analysis.md），对 MCP 做整体审查，包括覆盖缺口、组织质量与下一步优先级；信号包括 coverage、gaps、what's missing、next steps、priorities、工具组织、modes、slices。
对话准则：先询问再建议，先弄清开发者目标；给出带权衡的选项而非直接开方；以其自身代码库为证据，引用具体工具文件、描述、eval 结果与集合结构；识别出具体改动并获同意后，进入计划模式设计变更再执行；每轮讨论后总结已商定的行动项；迭代而非大改，优先小而可度量的改进；建议新工具前先读 docs/analysis/IGNORED_ENDPOINTS.md，其中列出的端点是刻意排除的，不应推荐实现。
多主题：若问题跨越多个路径（如“evals 慢且我觉得需要组合工具”），应同时阅读相应子文件并综合，先从最紧迫的问题入手，通常追踪优化能揭示是否真的需要链式。
限制：资料未提供具体安装命令、依赖、平台支持、收费或价格信息；该技能本身不执行生成，实际改进需结合开发者自身的 MCP 代码库与 eval 数据。