MCP服务器里写Prompt模板，怎么优雅地让LLM自己选择工具？

我之前也踩过这个坑，后来发现最管用的不是把描述写长，而是给每个工具加一个“触发条件”字段，比如“当用户提到退款且订单状态为已发货时，优先调用这个”。模型对结构化信息的理解比纯散文可靠得多，响应速度也没明显变慢。另外你试过在工具参数里加约束吗？比如用枚举值代替自由文本，或者把必填参数和可选参数分开，Claude选错参数的概率能降一半。至于让模型先思考再调用，我觉得得看场景——如果是简单操作，反而容易画蛇添足；但如果是涉及多步骤的判断，不如在MCP里设计一个“意图确认”工具，让模型把候选工具和参数先列出来给你确认，虽然多一步交互，但稳很多。还有个偏门技巧：在工具描述开头用一句“当且仅当……时使用”，排他性描述比正面描述更有效。

你这问题我太有同感了，之前搞MCP的时候也是被工具选择折磨得够呛。后来我发现一个比较管用的土办法，就是别把工具描述写成说明书，而是写成“这个工具是干嘛的、什么时候千万别用”这种带边界感的话术，比罗列参数有效得多。另外你可以试试把工具的输入参数设计得更“笨”一点，比如把多个容易混淆的参数合并成一个JSON字符串，让模型只负责填关键字段，这样它出错的空间就小很多。至于让模型先确认意图，我试过在工具描述里加一句“调用前必须先用一句话复述用户需求”，虽然不能100%稳定，但至少能拦住一半的瞎调用。还有个小技巧，如果某些工具确实容易搞混，不如干脆在系统Prompt里用“如果用户提到XX，一定是工具A，绝不要用工具B”这种强约束句式，比长篇大论管用。响应速度的问题，其实可以牺牲一点首token延迟，把工具描述压缩成关键词列表，然后在工具内部做模糊匹配，反而比让LLM硬理解更稳。总之核心思路就是“减少模型的自由发挥空间”，把决策逻辑往代码里挪，而不是全压在Prompt上。

这个坑我踩过，后来把工具描述改成“触发条件+输入输出”的结构，比如“当用户提到订单状态时调用此工具”，效果比单纯写功能清楚很多。另外别把说明全堆在系统prompt里，把关键约束写进工具本身的description，模型调用前会优先看那里。至于确认意图，我试过在工具里加个必填的confirm参数，让模型传true才执行，虽然多一步但明显减少乱搞。你那边工具数量多的话，建议按业务场景分组成几个子服务器，不然模型选择成本太高。

说实话你这问题我踩过不少坑，后来发现与其堆描述不如给每个工具加个“适用场景”和“反例”字段，模型选错率直接降一半。另外我习惯在prompt里加一句“如果用户意图模糊，先调用一个轻量的意图确认工具”，比硬让它思考稳定得多。还有个小技巧：把高频组合工具预先封装成一个复合操作，参数少了错误率自然就下来了。

之前我也踩过这个坑，后来干脆把每个工具的描述改成了“触发场景+反例”的结构，比如“当用户问X时用这个，但如果只是聊Y千万别调”，效果立竿见影。还有个土办法是给工具名字加前缀，像“get_”和“check_”区分查询和操作，模型不容易懵。另外你提到确认意图，我试过在描述里加一句“调用前先判断参数是否完整，缺就问用户”，响应会稳很多，但代价是偶尔多一次交互，得自己权衡下。

试试把每个工具的description写成“当用户想要X时用这个”，比列参数管用，亲测有效。

工具描述别堆细节，把触发条件和参数示例写清楚，模型选错概率能降一大截。

我当时也踩过这个坑，后来是把工具描述改成了“触发条件+输入示例+反例”的结构，比如“当用户提到报销但没给金额时，必须追问”，效果比单纯写“用于报销”好很多。另外别在系统Prompt里堆规则，把关键约束塞进工具描述本身，模型调用时反而更聚焦。你现在是一个工具一个工具试，还是所有工具一起上？如果工具多，建议先做个简单的意图分类前置，让模型先选类别再选具体工具，错误率能降不少。

试试把工具描述改成“动词+场景”的格式，比如“查库存：下单前确认数量”，模型选错的概率直接降一半。

再就是给关键工具加个“确认参数”的步骤，让模型先输出JSON再调用，比让它自由发挥稳多了。

我现在是给每个工具前面加个“触发场景”字段，比如“当用户提到报销时用这个”，比单纯列参数管用得多。另外把最常用的工具描述控制在50字以内，冷门的细节挪到MCP服务器端做二次校验，Prompt只留关键意图词。你试过把工具分组吗？我这边把同类API合成一个工具，靠第一个参数做路由，模型选错概率直接降了一半。

试过把工具描述按“触发场景+输入输出示例”来写，比单纯堆功能说明管用不少，模型选错率明显降了。另外可以在Prompt里加一句“不确定时先输出候选工具编号让用户确认”，比让它自己瞎猜强。不过响应速度确实两难，我后来是把长描述挪到工具定义里，主Prompt只留一行“所有工具见下方列表，按需调用”，给模型减负。你试试把工具名改成动词开头，比如“查询订单”比“订单查询”命中率高很多。

我之前也踩过这坑，后来是把工具描述改成“触发条件+输入输出示例”的格式，模型选错的概率明显降了。另外别在系统Prompt里堆太多规则，把关键约束塞进每个工具的描述开头，反而更管用。如果你用的是Claude，试试让它先输出一个简短的意图判断（比如“这个请求需要调用XX”），再走工具调用流程，比直接让它选稳很多。最后提醒下，参数校验逻辑最好也写在服务器端，别指望模型每次都老实。

这个坑我太熟了，之前折腾MCP的时候也是被工具选择折磨得够呛。后来发现一个比较管用的思路是别把Prompt当说明书，而是当“路由规则”——每个工具描述里只写清楚“什么时候用我”和“用我前必须确认什么”，少写参数细节，参数结构放到工具本身的input schema里去约束。这样模型在选择阶段负担小，等它真调用了再按schema校验，能挡掉不少乱传参的情况。另外你说让模型先思考再调用，其实可以试试在工具描述里加一句“如果你不确定该不该用本工具，先不要调用，而是输出一个简短的问题来确认用户意图”，这比单纯让它“思考”更有效，因为给了它一个明确的行动路径。还有个小技巧，如果某些工具经常被混淆，就在描述里故意加上“不要和XX工具混淆”的对比提示，实测对Claude这种模型挺管用的。最后关于响应速度，我的做法是系统Prompt里只放最核心的规则（比如三条以内），其余全塞进工具描述里，这样模型只在需要时才加载那部分上下文，比全堆在开头强多了。

试试给每个工具加个固定格式的“适用场景+反例”，效果比长描述好，模型选错率明显降了。

试过把工具名起成动词+名词的结构，比如getUserInfo改成fetch_user_profile，模型命中率高不少。另外在描述里加一两个典型参数示例，比写一堆规则管用。你要是实在纠结，可以让模型先输出一个json格式的意图确认，再决定要不要真调工具，多一步但稳很多。

碰到过一模一样的问题，后来我把工具描述从“功能说明”改成了“决策树式”的写法，每个工具开头先写清楚“当用户提到XX场景时选我，当用户想YY时千万别选我”，效果立竿见影。你那个让模型先思考再调用的思路其实方向对，但别指望它自己稳定，我试过在system prompt里加一句“调用前必须用一句话复述用户意图并匹配工具名”，准确率能提两成左右。另外参数乱传的问题，我是在MCP那层做了个轻量的schema校验，不合法就直接返回错误+正确示例，让模型自己纠正，比在prompt里反复强调有用得多。还有个野路子，把最常用的三个工具描述精简到50字以内，剩下的全塞到工具列表后面，实测Claude对靠前的工具调用倾向会强很多。你要是工具数量超过8个，建议按业务域拆成多个MCP server，别全堆一个里，模型选择负担小一半。

你这问题我太熟了，折腾一圈下来感觉最有效的还是把工具描述写成“触发条件+反例”的格式，比如“当用户明确提到XX关键词时才用这个，否则别碰”。另外别把所有工具都堆在Prompt里，MCP支持动态加载的话就按意图预筛一波，只暴露两三个候选给模型。还有个土办法，在工具返回结果里加个“你确定这是用户要的吗”的确认字段，强制模型在调用前多读一遍参数，出错率能降不少。

有个土办法挺管用，就是给每个工具加个“适用场景”字段，用两三个真实案例写清楚什么时候该调它，比单纯列参数有效得多。另外我这边试过在工具描述里加个“如果拿不准，别急着调用，先问用户”的提示，模型反而会主动跟你确认意图，比让它硬选强。Prompt太长的问题，可以试试把通用规则压缩成一句顺口溜，比如“查数据用A，改状态用B”，模型记忆负担小很多。你那些内部API是偏查询型还是操作型的？不同类型可能得区别对待。

我之前也踩过这个坑，后来是把工具描述改成“触发条件+输入示例”的结构，比如“当用户提到报销审批时调用此工具，参数格式参考：{action: approve}”，模型准确率一下子高了不少。另外别再堆长Prompt了，可以在MCP层做个中间校验，让模型先输出一个结构化意图（比如JSON），你解析确认后再真正执行，相当于加道保险，虽然多一次往返但稳定多了。还有个歪招，就是把常用的错误参数组合写进few-shot示例里，模型见过错例反而更不容易错。

我之前也踩过这个坑，后来发现最管用的其实是把工具描述按“触发条件+输入输出示例”来写，而不是堆功能说明。比如“当用户提到报销时用这个工具，参数date必须是YYYY-MM-DD格式”，模型犯错率明显降了。另外我试过在prompt里加一句“不确定就反问用户”，比让它“思考”靠谱，但得限定最多反问一次，不然容易卡对话。不过你这情况会不会是工具太多导致选择困难？可以试试按场景分组，在描述里加上“仅当xx场景才使用”的限定词。