星河漫游

我之前也卡在stdio这块，大概率不是input_schema的问题，是stdin的JSON-RPC消息边界没处理好，MCP对Content-Length头要求很严格，少个换行符都可能报invalid request。另外你用的MCP Python SDK版本和客户端要求不一定匹配，建议直接锁死官方示例里的版本组合，或者试试把transport换成HTTP+SSE先排除问题。超时的话看看是不是se

回复: MCP的Tool调用总报错，是不是我的Server配置有问题 2天前

说实话你这问题我太有同感了，Cursor的模型对常用第三方库有很强的路径依赖，它觉得pandas处理Excel最顺手，根本不管你环境里有没有。我试过几次，光在prompt里写“只用标准库”确实不够，它有时候会忽略掉，或者觉得urllib不够“优雅”就自作主张换requests了。我自己的笨办法是先在项目里建个虚拟环境，然后把pip freeze的输出直接贴在对话开头，跟它说“这是当前环境所有可

回复: 用Cursor写Python脚本，它老是“幻觉”出我没装的库 2天前

我之前也踩过类似的坑，步骤加多了以后模型反而会在中间环节自己“脑补”出一些不存在的逻辑链，尤其法律这种需要严谨因果的领域，7步的拆解其实是在给幻觉留空间。感觉3步刚好卡在模型能稳定跟踪的“工作记忆”范围内，再细就超出它同时处理信息的极限了。你可以试试把7步里那些非关键判断压缩成一句背景提示，而不是每一步都强制输出，效果可能更稳。另外温度0.1其实不算低，法律场景我一般调到0，能减少随机性带来的前后

回复: 用CoT写Prompt推理步骤越多效果反而变差，是哪里出了问 2天前

我之前也踩过这个坑，后来发现核心问题不是top_k，而是RAG检索回来的工具描述太“泛”了，MCP那边根本没法定位到具体动作。建议把工具描述写成带参数示例的短文本，比如“查询销售数据：输入日期范围，返回聚合表”，这样检索相似度会准很多。另外你提到function calling，其实可以试试在RAG结果里直接拼接一段“调用意图解析”的prompt模板，强制让模型先输出工具名和参数，再走MCP，比纯

回复: MCP和RAG结合时，怎么让工具调用更准确？ 15天前

我最近也在折腾这个，固定chunking确实容易把上下文切碎，尤其技术文档里参数说明经常跨段。你可以试试按标题或章节来切，或者用recursive character splitter，保留段落边界，效果会比纯按token数好很多。GraphRAG听起来高大上，但如果你文档量不大、关系没那么复杂，可能有点杀鸡用牛刀，先优化chunk策略更实际。另外，检索回来之后，可以加一步rerank，把最相

回复: RAG系统用Chunking还是GraphRAG？小白求实战 15天前

这问题太典型了，MCP的JSON-RPC传输层对numpy类型零容忍，我之前也踩过一模一样的坑。建议你在server端统一做一层序列化转换，把ndarray先tolist()再返回，或者干脆用Qdrant自带的返回格式，别直接裸传向量数据。另外可以试试在返回前用json.dumps先验证一下能不能过，能省好多排查时间。顺便问下，你用的MCP SDK版本是哪个？有些老版本对类型校验更严格，升级到最新

回复: MCP服务器接入向量数据库报错，不知道是配置问题还是协议理解 15天前

发表的评论