Using the optimizer's find_tool + call_tool meta-tools with an LLM agent (vmcp v0.40.1), call_tool itself works fine when it's called exactly right:
call_tool({"tool_name": "grafana-opt_search_dashboards", "parameters": {}}) → returns results
But the two-level shape — tool_name at the top, the target tool's own args nested under parameters — trips the model up constantly, and every malformation is a hard error the model then loops on. The common ones I see:
tool_name nested inside parameters → call_tool failed: tool_name is required (from the model's point of view it did pass tool_name, just one level too deep)- the target tool's args placed at the top level next to
tool_name instead of inside parameters → the target tool then reports its own missing arg, e.g. apiVersion is required
- the model calling the meta-tool through itself →
tool not found: mcp_toolhive_call_tool
Because these come back as plain errors with no correction hint, the agent tends to retry the same malformed call — I've watched it fail 3-4 times in a row on identical arguments before giving up.
Two things that would help a lot:
- Be lenient about the obvious case: if
tool_name is missing at the top level but present inside parameters, hoist it (and treat the rest of parameters as the target args). Likewise if a target arg ends up next to tool_name.
- When it does reject, return a short schema-guiding message (
expected {tool_name, parameters}, got ...) so the model can self-correct instead of looping.
The handler is correct as-is — this is about making the meta-tool robust to how models actually call it, which is more or less the whole point of the optimizer layer. Same ergonomics area as #4357 (dynamic find_tool description).
Version: vmcp v0.40.1.
Using the optimizer's
find_tool+call_toolmeta-tools with an LLM agent (vmcp v0.40.1),call_toolitself works fine when it's called exactly right:But the two-level shape —
tool_nameat the top, the target tool's own args nested underparameters— trips the model up constantly, and every malformation is a hard error the model then loops on. The common ones I see:tool_namenested insideparameters→call_tool failed: tool_name is required(from the model's point of view it did pass tool_name, just one level too deep)tool_nameinstead of insideparameters→ the target tool then reports its own missing arg, e.g.apiVersion is requiredtool not found: mcp_toolhive_call_toolBecause these come back as plain errors with no correction hint, the agent tends to retry the same malformed call — I've watched it fail 3-4 times in a row on identical arguments before giving up.
Two things that would help a lot:
tool_nameis missing at the top level but present insideparameters, hoist it (and treat the rest ofparametersas the target args). Likewise if a target arg ends up next totool_name.expected {tool_name, parameters}, got ...) so the model can self-correct instead of looping.The handler is correct as-is — this is about making the meta-tool robust to how models actually call it, which is more or less the whole point of the optimizer layer. Same ergonomics area as #4357 (dynamic
find_tooldescription).Version: vmcp v0.40.1.