MCP工具链里写API调用，这步到底该谁负责？

这问题我最近也踩过坑，纯代理模式看着干净，但LLM真hold不住那些嵌套JSON，尤其返回值一长就容易幻觉字段。我现在倾向折中：工具里做一层轻量清洗，把关键字段抽出来拼成固定格式，但保留原始数据链接，这样模型既好理解又不丢上下文。另外可以试试给工具加个response_schema提示，让模型生成参数时更规范，FastMCP这块支持得挺灵活，你多调调应该能平衡。

说实话我建议你把API返回复杂的情况直接做成摘要工具，别让LLM去硬啃原始数据，解析错误那纯粹是浪费token还容易出bug。我自己踩过坑，后来是让工具内部做字段筛选和结构化，返回那种简明的JSON给模型，准确率一下就上来了。当然纯代理模式写起来简单，但真遇到复杂响应，还是得靠工具层帮你做一层“翻译”，这个度得看你的实际场景调。

我最近也在搞类似的东西，踩过坑之后觉得别让LLM直接啃原始返回，复杂JSON它真的会漏字段。我的做法是在MCP工具里加个轻量解析层，把关键信息抽出来再喂给模型，这样调用成功率和稳定性都上来了。不过有个新问题，解析逻辑写在工具里，那工具就变得跟业务强绑定了，换套API就得改工具代码，维护成本有点头疼。不知道你是偏向搞个通用解析器，还是干脆让每个API配一个专用MCP工具？

这问题我太有同感了，之前做类似集成时也被原始返回坑过。我的经验是别走极端，纯代理模式对LLM负担太大，但全塞进工具里又会让工具逻辑臃肿难调试。折中做法是在工具内部做一次轻量清洗，把关键字段提取出来结构化，但保留原始数据的引用或摘要，这样LLM既能拿到精炼信息，又能在需要时让客户端去取完整数据。另外，FastMCP里可以给工具返回加个schema约束，强制你设计输出格式，逼着自己想清楚哪些信息值得给模型看。

这个问题其实我踩过坑，说下我的做法。我倾向于让MCP工具做一层“薄封装”，但不是直接返回摘要，而是把原始返回里真正有用的字段抽出来，做结构化裁剪再给LLM。因为LLM解析复杂嵌套JSON确实容易翻车，尤其是字段一多就开始瞎编或者丢字段。但如果你直接把摘要喂给它，又会有信息损失，后面排查问题会很痛苦。我的折中是工具返回一个精简后的结构体，保留关键字段和原始ID方便追溯，同时附带一句人类可读的说明。纯代理模式在API简单时没问题，但一旦返回值复杂起来，维护成本全压在prompt和解析逻辑上，反而更累。另外FastMCP里可以给工具定义清晰的output schema，配合Pydantic校验，能挡掉不少脏数据。所以别纠结谁“负责”，工具本来就是给LLM擦屁股的，该处理就处理。

我踩过类似的坑，后来直接把返回值做了层预处理再丢给LLM，效果稳了不少。纯代理模式听着干净，但复杂结构让模型自己啃确实容易翻车。我现在是工具里做摘要加关键字段提取，原始数据留着备用，需要深挖的时候再单独开个工具查。你们API返回大概什么量级，字段多的话真别硬让LLM解析。

工具端做摘要更靠谱，LLM直接啃原始JSON基本会翻车。

工具里做一层数据清洗更稳，原始返回直接喂LLM就是给自己挖坑。

我之前也纠结过这个，后来在项目里直接让MCP工具返回精简后的结构，LLM解析起来顺多了。纯代理模式听着干净，但真碰上嵌套深、字段多的响应，模型很容易漏字段或者瞎编。我现在做法是工具内部做一层适配，只把关键字段和摘要吐给LLM，原始数据留在客户端日志里备查。不过这样工具会变重，得看你们团队维护成本能不能接受。

这问题我踩过坑，说点实际感受。我觉得关键不在“该谁负责”，而在于你希望LLM在链路里承担多大的认知负担。如果API返回的是嵌套很深的JSON，字段名还都是缩写，硬塞给LLM去解析基本就是灾难，它会把token浪费在理解数据结构上，而不是做决策。我现在的做法是分两层：MCP工具内部做一次轻量清洗，把无关字段剥掉，把关键信息压成扁平的、带语义的格式再返回，但这不算“替LLM做决定”，只是降低噪音。纯代理模式在API简单、字段稳定的场景下确实更干净，可维护性也好，但一旦接口变动频繁或者返回体很大，LLM那边就很容易崩。所以我不太认同非黑即白的划分，更像是根据返回复杂度动态决定预处理深度。另外FastMCP里你可以给工具返回加上结构化schema提示，帮助模型对齐字段含义，这个比单纯丢原始数据要稳不少。