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

其实你这个问题我踩过类似的坑，试来试去感觉关键得看工具本身是“通用型”还是“专用型”。像写周报这种目的性很强的，把完整指令塞进description里确实容易被模型当成无关细节忽略，尤其当它忙着解析参数时。我现在的做法是，把“角色设定+格式要求”压缩成一句话放在工具描述开头，后面跟具体的参数说明，这样模型在决定调用哪个工具时就已经看到了约束。至于system prompt，我一般只放全局性的规则，比如“所有输出都用中文”这种，避免跟具体工具逻辑打架。MCP那个prompts资源我也试过，但感觉它更适合交互式会话的起始模板，不太适合被工具内部强制引用。另外有个小技巧，你可以在工具返回结果里带上“下次请按此格式”的提醒，相当于在对话流里二次强化，比单纯靠描述字段稳得多。不过说实话，不同模型对description的服从度差异挺大，Claude 3.5以后明显好很多，老版本可能就得靠把指令拆进参数默认值里逼它就范了。

说实话这个问题我折腾过挺久的，最后得出的结论是：别把指令全押在description里，也别全塞进system prompt。description字段本质是给模型做工具选择时的摘要，它得保持简洁聚焦，你塞一大段周报格式要求进去，模型检索时反而容易忽略关键触发词。我现在的做法是把“你是什么角色+输出骨架”这种核心约束放在工具描述的前两三句，具体细节（比如字段示例、语气要求）放到工具返回的schema里，让模型先调用工具再看到详细指令。至于MCP那个prompts资源，我理解它更适合做多轮对话的预设场景，比如“生成周报”这个动作本身需要用户补充项目背景时才用得上，跟你说的“封装固定指令”不是一回事。另外如果你担心system prompt污染其他工具，可以试试在系统提示里加一句“当调用周报工具时，必须严格遵循工具描述中的格式要求”，这样权重会高很多。反正我踩过的坑是，模型经常把description当参考而不是指令，所以关键约束我会在工具返回值里再强调一遍，双保险。

建议放工具描述里，但把格式要求写进参数约束，比单独描述更稳。prompts资源更适合多步流程，单工具用不上。

说实话这个问题我当初也卡了很久，试来试去感觉最靠谱的还是把指令拆两层：工具description里写“这个工具负责生成周报，输出结构包含本周完成、下周计划、风险点”，把具体语气、格式细节塞进prompts资源里让模型主动去调。因为MCP的prompts资源其实就是给模型一个“发现并加载”的入口，比硬塞进system里更灵活，而且不会污染其他工具的上下文。不过有个坑是Claude有时候不会主动去读prompts资源，除非你在工具描述里明确写一句“调用前先加载周报prompt模板”，这样相当于给它一个显式触发器。另外你提到的system prompt被忽略，很可能是描述太长了，模型注意力被稀释——我一般只把全局规则放system，比如“所有输出用中文，技术术语保留英文”，工具特有的指令全放description里，但description开头一定要用动词祈使句，像“生成周报时，必须按以下三步执行”，这样触发率会高很多。还有个偏方是直接把关键格式要求重复两遍，一遍在description开头，一遍在结尾，实测对Claude这种注意力机制挺管用，就是看着有点蠢。总之别指望一个位置解决所有问题，MCP这玩意儿本来就得靠组合拳。

说实话这个坑我也踩过，后来发现关键得看工具被调用的上下文。你说的那种“你是个周报助手”这种角色设定，放description里确实容易被模型当成普通说明忽略，尤其是当工具列表很长的时候，权重会被稀释。我的做法是，如果这个prompt跟工具强绑定、只在特定任务里用，就放进工具描述的前三句话，而且要写得像指令而不是说明，比如直接写“你必须严格按以下格式输出”会好很多。但如果你想让它影响所有相关调用，比如不管哪个工具都希望模型保持某种语气或结构，那放system里更稳，只是得注意别写得太啰嗦，不然其他工具也会被带偏。至于MCP的prompts资源，我理解它更像是一个可复用的模板库，适合你主动去选择调用，而不是自动生效的规则，所以跟你的需求不完全一样。我现在一般是这样：全局风格放system，单个任务的强约束放工具描述，而且会在描述里重复一遍关键格式要求，算是双保险。你可以试试把周报模板拆成“角色”和“格式”两块，角色放system，格式细节放工具侧，这样模型抓取信息的负担小很多。

用prompts资源吧，description塞太多指令模型确实容易犯迷糊，system里又太全局了。

我最近也在折腾这个，试下来感觉放description里确实容易被忽略，尤其是工具多的时候。我是把那种通用的角色设定放system，具体格式要求塞进description，但会用很明确的“必须”“禁止”这类词，再加个示例输出，命中率会高不少。MCP的prompts资源我也试过，适合那种需要用户手动确认再用的场景，比如一键生成周报模板，但纯自动调用时还是description更直接。说到底可能得看你这个工具是固定流程还是灵活交互，前者塞system也行，后者还是得靠description把约束写死。

放description里容易被模型选择性忽略，放system又污染全局，还是用prompts资源吧，专门干这个的。

我最近也在搞这个，试下来感觉放description里确实不太稳定，模型有时候会把它当成普通说明而不是强指令。后来我把那种固定格式要求拆出来放到system prompt里，工具描述只留输入输出参数说明，效果好很多。不过你说的MCP prompts资源我也在观望，感觉它更适合给用户主动选模板的场景，不太适合自动触发。你要是担心互相干扰，可以试试每个工具自带一套完整描述，别依赖全局system，虽然冗余但可控性强。

说实话你这问题我也踩过坑，我的经验是别把指令硬塞进description，那字段本质是给模型看“这个工具能干嘛”，塞太多格式要求反而容易被截断或忽略。MCP那个prompts资源确实就是干这个的，相当于把提示词做成可复用的模板，调用时再动态拼进对话里，比放system里干净多了。你要是担心影响其他工具，可以把周报逻辑拆成独立server，或者用prompts+工具组合的方式，让模型先取模板再调工具，这样职责清晰很多。

说实话我也踩过这个坑，我的做法是核心指令放system，但用工具名和description做触发条件，比如“generate_weekly_report”里再强调一遍格式要求，双保险。MCP那个prompts资源我试过，感觉更适合给用户主动调用，不适合自动触发。另外建议description里别写太长，把关键约束放前面，模型抓取概率会高不少。

我也踩过这个坑，description里写太长确实容易被模型选择性忽视，尤其工具多的时候。现在我的做法是：把核心行为准则放system，但只放那种全局性的约束，具体到每个工具的输出格式就精简成几个关键词塞description里，配合MCP的prompts资源做切换模板，效果比单放一边稳。你试试把周报格式拆成“分点+数据优先”这种短指令放description，系统里只留角色定位，模型反而执行得更准。

我最近也踩过这个坑，实测下来感觉description里写指令确实容易被模型当“背景噪音”忽略掉，尤其当工具列表一长，模型注意力分配的时候优先级特别低。但全塞system prompt又太笨重，别的工具调用时会被这些冗余指令干扰，甚至出现角色串味。我的做法是把“稳定的、跨工具的行为规范”放system，比如通用的输出格式、语气要求；而“某个工具特有的、触发时才需要的上下文”放description，并且尽量写具体，比如直接给例子“输入周报数据后必须按：本周进展/问题/下周计划来组织”。至于MCP的prompts资源，我觉得它更适合做“可复用的模板库”，比如预设好各种周报场景的完整prompt，让用户或模型主动去拉取，而不是被动塞进每个请求里。我自己试过在description里加“如果用户要求写周报，必须先调用getWeeklyReportTemplate”这种强制指令，效果比直接写描述好一些，你可以试试让工具自己触发模板获取。另外提醒一下，如果你用Claude，它的工具调用前会先做一次意图判断，所以description前几个字特别重要，我一般把最关键的动作词放最前面。

我个人觉得放description里其实够用，但得把指令写得更强制一点，比如明确说“必须严格按以下格式输出，否则无效”，不然模型确实容易当参考信息跳过。system prompt全局放周报模板的话，其他工具调用时可能被带偏，尤其如果模型把整个系统提示都当背景噪音。MCP那个prompts资源我试过，感觉更适合给用户手动选场景触发，而不是自动套用，你这种固定流程的工具还是description里写死更靠谱。

说实话这个坑我也踩过，放description里确实容易被模型选择性忽略，尤其工具多的时候。我的经验是那种强约束的格式指令塞system里更稳，但得写清楚只对特定工具生效，不然其他调用确实会被带偏。MCP那个prompts资源我试过，更适合做可复用的模板预设，不是用来硬绑工具行为的，你可以把固定格式放prompts里，description只留功能描述试试。

说实话我之前也踩过这个坑，放description里确实容易被忽略，尤其工具多了之后模型权重会分散。我的做法是像这种强格式要求的指令直接写进system prompt，但用分隔符把不同工具的专属规则隔开，实测比放description稳。至于MCP那个prompts资源，它更适合做一次性模板调用，不太适合作为工具运行时持续生效的约束，你可以把周报模板拆成“生成草稿”和“按格式润色”两步，前者走prompts，后者走工具。

我试过放description里被忽略，后来干脆用prompts资源做模板，调用时直接传参，稳多了。

我最近也在折腾这个，踩过一样的坑。我的做法是：跟特定工具强绑定的指令放description里，但开头一定要写清楚“当调用此工具时，必须遵循以下规则”，这样模型通常不会忽略；全局性的行为约束才放system。至于MCP的prompts资源，更像给用户手动选择的预设模板，不适合当自动注入的指令，你可以试试把周报格式模板拆成工具输入参数，逼模型自己填，比纯指令可靠得多。

建议把通用指令放system，工具专属规则放description，prompts资源适合做多步骤模板。

说实话这个我踩过坑，放description里确实容易被模型选择性忽略，尤其工具多的时候。我的做法是把强约束的格式要求塞进system prompt，工具描述里只留触发条件和输入参数说明，这样稳定性高很多。MCP那个prompts资源我试过，更适合做可复用的多轮对话模板，跟工具调用场景不太搭，你写周报的话还是建议system prompt为主。