MiniMax Agent工具调用失败主因是参数错误或schema不合规：需确保parameters为合法JSON对象且type="object"，properties中参数type仅限六种基础类型，required字段须精确匹配properties键名；修复LLM输出违规值需加enum、范围约束或本地校验；统一snake_case命名，显式声明必填项并移除default空值。

MiniMax Agent调用工具时出现参数错误，比如传入空字符串、类型不符、必填字段缺失或格式违反schema约束，会导致工具调用直接失败并返回Invalid Parameter或Tool execution failed类报错，无法进入实际执行环节。

检查工具定义中的parameters是否符合JSON Schema v7规范

MiniMax平台对tools字段中每个tool的parameters子对象执行严格校验，不合规的schema会直接拒绝注册，Agent根本不会看到该工具。

第一步：确认parameters是一个合法JSON对象，不是字符串、null或数组；它必须包含type字段，且值只能是"object"（不允许写"Object"或"object | null"）。

第二步：检查properties下每个参数的type声明——只接受"string"、"number"、"integer"、"boolean"、"array"、"object"六种，禁止使用联合类型（如"string | number"）或自定义类型名（如"order_id"）。

第三步：验证required字段为字符串数组，且其中每一项都精确匹配properties中已定义的键名，大小写、拼写、下划线位置必须完全一致；【若required里写了"userId"但properties里定义的是"user_id"，工具将被静默忽略】。

修复LLM生成的参数值违规问题

即使工具定义正确，LLM仍可能输出非法参数值，例如空字符串、超出范围的数字、不符合枚举值的字段等。这类错误在调用时才暴露，需从输入侧拦截。

方法一：为关键参数添加enum约束。比如订单状态只能是["pending", "shipped", "delivered"]，LLM就无法生成"done"或"finished"等无效值。

方法二：对数值型参数设置minimum/maximum或minLength/maxLength。例如order_id要求8位纯数字，就在schema中写"type": "string", "minLength": 8, "maxLength": 8, "pattern": "^d{8}$"。

方法三：在LLM调用前插入轻量级参数校验层。收到tool call后，不直接执行，而是先用Python的jsonschema.validate()做本地校验；校验失败则返回明确错误消息给LLM，触发重试——这比让MiniMax服务端报错再重试更可控。

避免工具名与参数名大小写/命名风格混用

MiniMax工具路由机制对名称完全敏感，大小写差异即视为不同工具或参数，极易导致“工具找到了但参数塞不进去”这类隐性失败。

统一采用snake_case命名所有工具名和参数名，例如query_order_status、order_id、tracking_number；严禁混用camelCase（如queryOrderStatus）、PascalCase（如QueryOrderStatus）或kebab-case（如query-order-status）。

【注意：tool.name必须与LLM生成的tool_calls[].function.name完全一致，一个字母大小写错误就会触发'Tool not found'】

调试时可打印LLM原始输出的tool_calls数组，逐字符比对name和arguments字段，确认无不可见字符（如零宽空格）或编码污染。

补全缺失的必填参数并禁用默认空值

LLM常把可选参数当必填，或把必填参数留空，尤其当描述中用了模糊措辞如“尽量提供”“如有则填”。MiniMax不接受null或空字符串作为必填参数值。

在工具描述中明确标注必填性：“user_id（必填，8位数字字符串）”，并在parameters的required数组中显式列出；同时移除所有"default": null或"default": ""字段——它们会误导LLM认为可跳过。

若业务逻辑允许某参数缺省，应在工具实现内部处理，默认值不要交给LLM填；否则LLM可能生成"user_id": ""，触发参数校验失败。