先看现象。把内部 160 个接口全注册成 Gemini 的 functionDeclarations，2.0 Flash 上请求返回 400，提示 tools 数量超出限制，减到 100 个就正常，但业务希望这些能力一次都能用。
原因不止一个，得分开看。单次请求的 functionDeclarations 数量有硬上限。还有一种是每个工具的 description 过长，把请求体推到体积上限。
还有一种情况，工具没做分组，全部塞进一次请求。
另外，SDK 把 MCP 里的工具全量展开，数量失控。
数一下实际下发的工具数量
python -c "import json;print(len(json.load(open('req.json'))['tools'][0]['functionDeclarations']))"接着按业务域拆成两批分别请求
python split_tools.py --by domain --out 'tools_batch_{}.json'做一轮意图分类再挂对应工具集
curl https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$G_KEY -d @route_req.json压掉冗长 description 后复测数量
python shrink_desc.py --max-chars 120 --in tools.json报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
白天有业务在跑，能验证的部分都压到了晚上做。
怎么算真的好了，看的是同一批现象。每批请求都返回 200，命中的 functionCall.name 在预期集合内，不再出现数量超限。
工具越多模型选错概率越高，按意图先缩候选集，比硬撑上限更划算。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。