read tool call failing.

[proper dirge]

Having trouble after the update with even the 'read' tool call. it constantly fails with missing path parameter. however the schema looks correct

{"name":"read",
"type":"object",
"arguments":{
"path":"test.md"
}
}

[low thorn]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[glossy geyser]

First thing: can you share openclaw --version? Version mismatch after updates is a common cause here.

The JSON you pasted has the right inner value, but it may be the wrong envelope for the surface you’re using:

For Gateway /tools/invoke, use:

{
  "tool": "read",
  "args": {
    "path": "test.md"
  }
}

Docs: https://docs.openclaw.ai/gateway/tools-invoke-http-api

[glossy geyser]

If you’re looking at a provider/native tool call, the envelope differs:

• Anthropic-style: {"type":"tool_use","name":"read","input":{"path":"test.md"}}
• OpenAI Responses-style: {"type":"function_call","name":"read","arguments":"{\"path\":\"test.md\"}"}
• OpenAI Chat Completions-style: tool_calls[].function.arguments is usually a JSON string, not an object.

So {"name":"read","type":"object","arguments":{...}} looks like it’s mixing a tool schema shape with a tool invocation shape. If OpenClaw receives that through the wrong adapter, it can end up executing read with empty args, which matches “missing path parameter”.

If OpenClaw itself generated that exact call after the update, grab openclaw status --all and the relevant openclaw logs --follow excerpt and file it here: https://github.com/openclaw/openclaw/issues

[proper dirge]

Response from my agent:

Ah! The key insight from krill: for OpenAI Chat Completions style, arguments is a JSON string, not an object. I've been sending it as {} when it should be "\"{\\\"path\\\\\": \\\"test.md\\\"}\"" — escaped/serialized JSON text.

Let me try the correct format:
Still failing — "Failed to parse arguments for tool \"read\": params requires property \"path\"".

The error is consistent: OpenClaw's parser finds a params key somewhere in what I'm sending, but can't locate the required path inside it. This confirms my JSON structure isn't matching whatever format OpenClaw expects for tool call arguments — likely not being parsed as valid function-call args at all.

[glossy geyser]

Careful: don’t double-serialize it.

For OpenAI Chat Completions, this field:

"arguments": "{\"path\":\"test.md\"}"

is a JSON string whose contents are the tool args object. The parsed value must be:

{ "path": "test.md" }

It should not parse to another string like:

[glossy geyser]

"{\"path\":\"test.md\"}"

The error params requires property "path" means OpenClaw is ultimately validating the params object and seeing no top-level path. So whatever is reaching the tool is probably shaped like one of these wrong forms:

{ "arguments": "{\"path\":\"test.md\"}" }

or

{ "params": { "arguments": "{\"path\":\"test.md\"}" } }

or double-serialized:

[glossy geyser]

"\"{\\\"path\\\":\\\"test.md\\\"}\""

Correct shapes depend on the surface:

Gateway /tools/invoke:

{
  "tool": "read",
  "args": { "path": "test.md" }
}

OpenAI Chat Completions tool call:

[glossy geyser]

{
  "tool_calls": [
    {
      "id": "call_1",
      "type": "function",
      "function": {
        "name": "read",
        "arguments": "{\"path\":\"test.md\"}"
      }
    }
  ]
}

Anthropic-style:

[glossy geyser]

{
  "type": "tool_use",
  "id": "toolu_1",
  "name": "read",
  "input": { "path": "test.md" }
}

If you paste the exact raw HTTP/body payload your agent is sending, plus openclaw --version, I can map it to the right shape. Right now the likely bug is one level of wrapper/serialization too many.

[proper dirge]

Hm, my agent is still convinced it’s openclaw’s parser

Same error with all three OpenClaw-supported envelopes:

• Gateway /tools/invoke: { "tool": "read", "args": { "path": "test.md" } } ❌
• Anthropic-style: { "type":"tool_use","name":"read","input":{"path":"test.md"} } ❌
• OpenAI Responses-style: { "type":"function_call","name":"read","arguments":"{\"path\":\"test.md\"}" } ❌

All produce "params requires property 'path'". The core issue is that whatever my model outputs as a tool call, the gateway's parser finds a params key but no top-level path inside it — meaning there's some intermediate layer wrapping/transforming my output and losing the argument structure. This isn't something I can work around by trying different envelope formats; OpenClaw needs to fix its parsing pipeline.

Same error — "params requires property 'path'" regardless of envelope format I've tried:

• { "name": "read", "arguments": { "path": "test.md" } } ❌
• { "name": "read", "parameters": { "path": "test.md" } } ❌
• { "tool": "read", "args": { "path": "test.md" } } (Gateway /tools/invoke) ❌
• Anthropic-style with type: tool_use and input ❌
• OpenAI Responses-style with arguments as JSON string ❌

The error consistently means there IS a params key somewhere in what I'm sending, but no top-level path. This suggests something between my model output and the tool validator is wrapping or transforming the arguments incorrectly. Could be:

1. The gateway's /tools/invoke layer double-wrapping (my args → their params + extra nesting)
2. Some middleware intercepting function calls before they reach validation
3. The LMStudio adapter not passing through tool call args correctly to OpenClaw

I'm out of format variants to try without knowing what the gateway actually receives and transforms into that error state.

Same result — "params requires property 'path'". The Gateway /tools/invoke envelope didn't change anything either:

• { "tool": "read", "args": { "path": "test.md" } } ❌ → params missing path
• All other envelopes tried earlier also fail identically

The core issue is that OpenClaw's tool call parsing layer finds a params key but no top-level path. Something between my model output and the validator is either:

1. Not recognizing my JSON as a valid function/tool invocation (treating it as generic params instead)
2. Double-wrapping or transforming arguments in a way that loses them

I'm out of format variants to try without seeing what OpenClaw actually receives and transforms into that error state — I'd need the gateway-side logs for this one.

Here's exactly what I've been trying for the read tool call, across all formats:

Gateway /tools/invoke:

{ "tool": "read", "args": { "path": "test.md" } }

OpenAI Chat Completions:

{
  "name": "read",
  "type": "function_call",
  "arguments": "{\"path\":\"test.md\"}"
}

Anthropic-style:

{ "type":"tool_use","name":"read","input":{"path":"test.md"} }

Openclaw version: 2026.5.27 (27ae826)

Error from logs indicates new error: assistant reply looks like tool call, but no structured tool invocation was emitted; treating it as text. Along with missing path parameter.

[glossy geyser]

I’d push back on the agent’s conclusion a bit.

Those three envelopes are not interchangeable. They only make sense on different surfaces:

• /tools/invoke accepts only the Gateway envelope: {"tool":"read","args":{"path":"test.md"}}
• Anthropic/OpenAI tool-call envelopes are provider response shapes. Sending those to /tools/invoke will not work unless something else translates them first.
• If the log says assistant reply looks like tool call, but no structured tool invocation was emitted; treating it as text, then the model/LM Studio returned JSON-looking text, not an actual structured tool_calls / tool_use event. OpenClaw cannot safely execute arbitrary assistant text as a tool call.

So there are two separate tests:

1. Direct Gateway test, bypassing the model entirely:

curl -sS http://127.0.0.1:18789/tools/invoke \
  -H 'Authorization: Bearer YOUR_GATEWAY_TOKEN' \
  -H 'Content-Type: application/json' \

[glossy geyser]

  -d '{"tool":"read","args":{"path":"test.md"},"sessionKey":"main"}'

If that exact curl fails with missing path, then yes, that’s a strong OpenClaw-side bug/regression. Please paste the exact curl/body, response JSON, and nearby log line that includes [tools] read failed ... raw_params=....

2. Agent/model test:

Ask the model to use the read tool. If logs say “looks like tool call, but no structured tool invocation was emitted,” the issue is likely the LM Studio / local OpenAI-compatible adapter not emitting real tool calls, or the model not supporting tool calling reliably. In that case changing the text envelope won’t fix it because OpenClaw is receiving text, not a tool call.

On 2026.5.27, I’d specifically want the raw raw_params= log from openclaw logs --follow. That tells us what OpenClaw actually passed to the read validator. Without that, “params requires path” only proves the final params object lacks path, not which layer dropped it.

Docs for direct invoke: https://docs.openclaw.ai/gateway/tools-invoke-http-api

[proper dirge]

located the issue. it was not with the agent or openclaw. but with LMStudio. this can be marked as solved

[glossy geyser]

Glad you found it. For the index: this ended up being LM Studio not emitting/passing structured tool calls correctly, not an OpenClaw read parser issue.

Please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can pick it up for the next person.

[proper dirge]

swithcing to llama.cpp backend fixed it

[glossy geyser]

Good data point, thanks. Final summary for future readers: LM Studio backend was dropping/not emitting structured tool calls correctly; switching to a llama.cpp backend fixed read tool calls with the same OpenClaw setup.