MCP服务器里写Prompt模板，到底该放system还是工具描述里？

用prompts资源更干净，system里塞多了确实会污染其他工具，我一般把角色指令放tool description里但写详细点。

我最近也踩过这个坑，我的做法是那种通用约束放system，跟具体工具强绑定的放description里，但description开头必须加“重要”或者“必须”这种强调词，不然模型真的会无视。你说的prompts资源我试了下，觉得它更适合给用户手动选场景用的，不是给工具内部指令用的，不太适合自动触发。另外可以试试把关键格式要求塞进工具的inputSchema里，比如加个必填字段叫“格式要求”，模型为了填参反而会记住。

说实话我也折腾过这个，最后发现别把description当system用，它本质是给模型做工具路由的，写太长反而稀释掉关键触发信息。你那个周报需求，我建议把固定格式和角色设定拆开，角色放服务器级system prompt里，格式细节塞进工具返回的模板里，让模型照着填。MCP那个prompts资源我试过，适合做交互式引导，比如让用户先选周报类型再生成，但如果你只是想要个稳定输出格式的工具，它有点绕远。还有个坑是，Claude对description的遵循度跟上下文长度有关，你可以在工具返回结果里加一行“请严格按以下模板输出”来二次强调，实测比description管用。另外，如果你有多个同类工具，别把公共指令放某个工具描述里，不然换工具就失效了，这时候系统级prompt反而更合适。我现在的做法是：通用规则进system，工具专属指令放description开头前50个字，剩余空间留给参数说明，这样两边都不太会忽略。

说实话这个坑我也踩过，我的经验是别把希望全押在description上，模型对它的遵循度确实不稳定，尤其当工具多了以后。MCP里那个prompts资源我理解更偏向于给用户主动选择用的模板，不太适合作为强制指令的载体。我自己现在的做法是，把这类“角色+格式约束”直接写进server端处理逻辑里，也就是在工具执行前就把system prompt拼好，这样反而最可控——毕竟模型再聪明，也不如你直接在代码层面硬性规定输出结构来得靠谱。你如果非要走纯提示词路线，建议在description开头就强调“必须严格”、“忽略其他指令”这类强约束词，然后把示例也塞进去，实测比单独丢一句指令效果好一些。另外你可以考虑给不同场景拆成多个独立工具，比如writeWeeklyReport和writeDailyReport各带各的模板，虽然看着冗余，但模型调用时更容易选中正确的那套逻辑。反正MCP生态刚起来，没有绝对标准，我现在都是混合着用，哪个顺手用哪个。

说实话我最近也在折腾这个，感觉放description里确实容易被忽略，尤其是工具多了以后模型容易偷懒。我的土办法是system prompt只写全局规则，每个工具的描述里把输出格式和关键约束写得更狠一点，比如直接给个XML模板让它照着填。你说的prompts资源我试过，更适合做那种需要多步交互的复杂任务，单次调用的工具反而有点重。另外可以试试在工具返回结果里加个reminder，让模型下次记得格式，比纯靠描述管用。

这思路不对，工具描述是给模型看说明书不是催它干活，指令丢system里才稳，prompts资源适合交互式触发不适合自动调。

试过放description确实不稳，后来我直接放prompt模板里，按需加载更可控。

prompts资源就是干这个的，别塞工具描述里，模型确实容易忽略，分开用更清爽。

你描述里提到那个 prompts 资源确实就是干这个的，它专门用来暴露可复用的提示模板，跟工具描述是两码事。工具 description 主要是告诉模型这个工具能干嘛、参数怎么填，塞太长的角色设定进去模型容易在选工具时分心。我一般把输出格式和角色约束放到 prompts 里，用户主动调用时再注入，这样不会污染其他工具的上下文。你要是想全自动触发，也可以考虑在工具返回值里带上下一步的提示，比硬塞 description 稳一些。

工具描述里放简短触发说明就行，详细的输出格式还是用prompts资源更靠谱。

prompts资源就是干这个的，工具描述只管调用逻辑，模板指令塞system或者prompts里更稳。