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

同款纠结过，后来发现放description里更稳，但得写得特别细，把输出格式和步骤都塞进去，模型基本不会跑偏。system prompt放太具体的东西确实会干扰其他工具，尤其工具多了以后容易串味儿。MCP那个prompts资源我试过，适合做交互式模板，比如你主动让Claude调用的场景，写周报这种还是靠工具描述触发更自然。你可以试试把指令拆成两部分：核心角色放system，具体格式丢description，我这么搞之后效果好多了。

我最近也踩过这个坑，放description里确实不稳，模型容易看心情忽略。后来我把任务专属指令全塞进server的system prompt里，其他通用工具调用没怎么受影响，感觉MCP每个工具的调用还是会带上全局上下文的。不过你说的prompts资源我也试过，那个更像预置模板库，适合手动触发，不太适合自动执行。个人建议是拆细点，把周报这种强指令放server级，弱指令才放工具描述里。

说实话你这个困惑我太懂了，刚玩MCP那会儿我也在这俩地方反复横跳。我的经验是，那种“你是个周报助手”的角色定义和输出格式要求，放工具description里其实最合理，但前提是description要写得足够结构化，比如用“当用户请求生成周报时，你需遵循以下规则”这种明确的触发句式，而不是光放一堆形容词，不然模型确实容易当废话忽略。至于system prompt，我建议只放全局性约束，比如“你是一个严谨的助手”这种，一个工具一个业务规则全塞进去肯定互相打架。你提到的prompts资源我倒觉得不是干这个的，它更像是给用户预置的对话模板入口，跟工具执行时的指令是两码事。还有个土办法，就是你在工具描述里把输出格式用XML或JSON示例写出来，模型对这种明确结构通常更听话，你可以试试。不过我也遇到过一些模型对description长度特别敏感，太长了反而会截断，所以还得控制篇幅，把最关键的约束放前面。

试过把指令塞description里，模型确实容易选择性失明，放system里又太霸道，蹲个靠谱方案。

我一般放description里，但会写清楚触发条件，system只放全局约束，不然其他工具调用确实容易跑偏。

说实话我一开始也纠结过这个问题，后来发现放description里更靠谱，但得把指令写得很死，比如“必须严格按以下格式输出”，不然模型确实容易犯懒。MCP那个prompts资源我试过，更适合当预设模板给用户手动选，而不是自动触发，你如果想让工具每次调用都带系统级约束，还是得在description里下功夫。另外你可以在工具描述里加个例子，告诉模型“如果输入是X就输出Y”，这样比纯命令式指令管用得多。

同感，放description确实容易被忽略，试试把指令写进tool schema的input参数里强制约束，比system稳多了。

放description里确实容易飘，我都是把核心约束塞system，工具描述只留触发条件。

prompts资源适合做多步流程，单工具还是system稳一点。

说实话我也有类似的困惑，试过把指令塞description里，结果模型经常自作主张简化格式。后来我干脆把这类固定模板用MCP的prompts资源封装，调用的时候显式传参，反而稳定不少，system里只留通用约束。你可以试试把周报格式写成prompt模板，工具description只写功能说明，这样职责清晰些。另外别怕影响其他工具，system里写清楚“仅当调用周报工具时”这种限定句，实测没那么容易串味。

其实你纠结的这个点很多人都有，我的经验是那种只影响单个工具行为的指令放description里最稳，但得写得很具体、带示例，不然模型确实容易忽略。全局性的风格约束才放system prompt，不然工具多了互相打架。MCP那个prompts资源我试过，更像是个模板仓库，适合你主动去调，不适合当自动触发的指令，跟你的场景不太匹配。你可以试试把周报格式要求拆成几个关键点塞进description开头，后面再跟工具参数说明，模型抓取率会高很多。

放description里确实容易被忽略，试试把核心指令塞进工具名和参数里会更稳。prompts资源适合做多步流程，但单工具场景还是description+参数校验最靠谱。

放system里太粗暴了，MCP的prompts资源就是干这个的，按需调用最稳。

description里塞指令容易被模型当噪音，建议单独定义prompt模板，工具里只留调用逻辑。

说实话我之前也踩过这个坑，放description里确实容易被忽略，尤其当工具多的时候模型注意力会分散。我的做法是核心的格式要求放system，但把“何时调用”和“输入输出结构”写进description，分工明确一点。至于MCP那个prompts资源，感觉更适合做可复用的模板库，而不是绑定某个工具的强制规则，你可以在调用时让模型主动去查。反正别指望模型每次都老老实实读全描述，关键约束重复写两遍也不丢人。

说实话我之前也踩过这个坑，放description里确实容易被忽略，尤其工具一多模型就犯迷糊。我的做法是那种“固定格式”的指令直接塞进system prompt，但用分隔符标清楚只对特定工具生效，其他工具调用没影响过。至于MCP的prompts资源，我理解它更像预置的对话模板，适合给用户手动选，不太适合自动触发，你可以把周报当prompt模板用，但工具描述里还是得写清楚输入参数。

prompts资源更适合，description塞太多指令确实容易被模型忽略，模板放system里又会污染其他调用，分开管理最稳。

说实话我之前也踩过这个坑，放description里确实容易被模型当背景噪音忽略，尤其工具多的时候。后来我基本把这类指令拆成两半：核心输出格式放system里，跟具体工具强相关的约束才放description，这样兼顾稳定性和灵活性。MCP那个prompts资源我也试过，感觉更适合做用户主动调用的模板，像周报这种高频固定场景反而不如直接混进system里来得省事。

说实话这个问题我也纠结过挺久，最后我的做法是分场景处理。像周报这种强格式要求的任务，我会把核心指令塞进description里，但一定要写得非常具体，比如直接给出输出模板的示例，而不是只写“你是周报助手”这种空话，模型看到具体格式样例时遵循率会高很多。system prompt里我一般只放全局性的约束，比如语气、通用输出规范，因为放太多工具专属逻辑确实会互相干扰，尤其当工具多了之后，模型容易把A工具的指令套到B工具上。至于MCP的prompts资源，我理解它更像是给用户主动调用的“预设模板”，适合那种需要交互式确认的场景，不太适合纯自动化的工具链。另外我有个小技巧，就是在description里加一句“如果用户未指定格式，必须严格按以下模板输出”，这样能堵住模型自由发挥的倾向。不过说实话，不同模型对description的敏感度差异挺大的，Claude相对听话，有些模型就爱偷懒，最后可能还是得靠你在调用端做一次后处理兜底。

说实话system prompt和工具描述我都试过，体感是描述里写太细确实容易被忽略，但全塞system里又会让模型在无关调用时也带着这层人设，反而干扰判断。我现在的做法是system只放全局规则，比如输出语言和格式底线，而周报这种特定任务的指令就放到工具描述的前半段，越靠前越有效。至于那个prompts资源，我感觉更适合做可复用的模板让用户主动选，不太适合当强制指令，毕竟它要客户端配合才能触发。

确实用prompts资源更合适，description塞太多指令反而容易被模型当成噪音忽略。

实践下来放description最稳，system影响全局容易串味儿，prompts资源适合做多套模板切换。