Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: kimi/kimi-code LLM tool call validation errors when parameters are missing-bug [1 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#55005•Fetched 2026-04-08 01:33:45
View on GitHub
Comments
2
Participants
3
Timeline
14
Reactions
2
Author
weesky2016-uiweesky2016-ui
Participants
J1awei-YangJ1awei-Yangweesky2016-uiweesky2016-uiyuanaichiyuanaichi
Timeline (top)
cross-referenced ×4referenced ×3commented ×2labeled ×2

name: Bug report about: LLM tool call validation errors when parameters are missing title: '[Bug] Tool calls fail with validation errors when required parameters are omitted' labels: bug, tool-calling, validation assignees: ''

Error Message

  1. Each call returns the same validation error

Error Type 1: read tool missing path parameter

Error Type 2: exec tool missing command parameter

Error Type 3: feishu_drive_file tool missing action parameter

  1. Single failure: If parameter construction fails, should error only once instead of repeatedly calling the same tool
  2. Friendly hints: Error messages should guide LLM on how to correctly fill missing parameters
  • If missing, immediately return structured error to LLM instead of sending to tool layer

Option 2: Error Feedback Optimization

Complete Error Log Timeline

  1. Each call returns the same validation error
  2. Single failure: If parameter construction fails, should error only once instead of repeatedly calling the same tool
  3. Friendly hints: Error messages should guide LLM on how to correctly fill missing parameters

Error Type 1: read tool missing path parameter

Error Type 2: exec tool missing command parameter

Error Type 3: feishu_drive_file tool missing action parameter

Root Cause

The core issues are:

  1. Fallback behavior on parameter construction failure: When LLM cannot correctly construct complex parameters, it may fallback to passing empty object {}
  2. Lack of pre-validation: System does not validate parameter completeness before sending
  3. Over-aggressive retry mechanism: After encountering validation errors, LLM attempts to call again but still uses the same empty parameters

Fix Action

Fixed

PR fix notes

PR #54491: fix(kimi): preserve valid Anthropic-compatible toolCall arguments in malformed-args repair

Description (problem / solution / changelog)

Summary

  • Problem: When using Kimi in Anthropic-compatible (anthropic-messages) mode, the malformed toolCall-arguments repair logic could fail to preserve otherwise-valid JSON arguments (resulting in missing/empty tool arguments).
  • Why it matters: Tool execution depends on correct toolCall.arguments; losing valid arguments can cause wrong tool behavior, failures, or unexpected “empty args” executions.
  • What changed: Adjusted the Kimi/Anthropic toolCall-argument repair path to keep valid, complete JSON arguments intact and only apply “balanced-prefix + short trailing junk” repair when the arguments are actually malformed.
  • What did NOT change (scope boundary): No changes to tool dispatch logic, tool allowlists, transcript storage, or non-Kimi providers.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

Root Cause / Regression History (if applicable)

  • Root cause: The malformed-args repair wrapper for Kimi/Anthropic streams treated some valid toolCall argument payloads as candidates for repair, and under certain stream delta patterns it could clear/override arguments instead of preserving the complete JSON object.
  • Missing detection / guardrail: Unit coverage focused on “valid JSON + short trailing junk” but didn’t adequately lock in “valid JSON must remain unchanged” across all relevant stream delta/event sequences.
  • Prior context (git blame, prior PR, issue, or refactor if known): Unknown.
  • Why this regressed now: Likely triggered by Kimi’s Anthropic-compatible streaming behavior (toolcall deltas containing } early / nested JSON / event chunking), which increased the chance the heuristic attempted repair at the wrong time.
  • If unknown, what was ruled out: Not an auth/key issue and not a tool registry/dispatch mismatch; reproduces at the stream parsing/repair layer.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/agents/pi-embedded-runner/run/attempt.test.ts (malformed toolCall args repair tests)
  • Scenario the test should lock in: When toolCall arguments are already valid JSON (including nested objects), the repair path must not alter or clear them; when valid JSON is followed by 1–3 trailing junk characters, it should repair to the valid object.
  • Why this is the smallest reliable guardrail: This bug is purely in the stream repair/parsing layer; unit tests can deterministically simulate deltas/events without requiring a live model.
  • Existing test that already covers this (if any): The suite includes a test for “trailing junk follows valid JSON”; this PR strengthens/extends coverage to ensure valid JSON remains intact.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

None (except improved reliability of tool execution for Kimi Anthropic-compatible runs).

Security Impact (required)

  • New permissions/capabilities? (Yes/No): No
  • Secrets/tokens handling changed? (Yes/No): No
  • New/changed network calls? (Yes/No): No
  • Command/tool execution surface changed? (Yes/No): No
  • Data access scope changed? (Yes/No): No
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • OS: macOS
  • Runtime/container: Node.js (local)
  • Model/provider: kimi-coding/k2p5
  • Integration/channel (if any): N/A
  • Relevant config (redacted): Provider set to kimi, model API anthropic-messages

Steps

  1. Configure provider kimi with Anthropic-compatible API (anthropic-messages).
  2. Trigger a tool call where arguments are a valid nested JSON object (e.g. {"path":{"a":"/tmp/report.txt"}}) and/or where streaming deltas include early } tokens.
  3. Observe tool call arguments during/after stream assembly.

Expected

  • Valid JSON arguments are preserved exactly and passed to tool execution unchanged.

Actual

  • Arguments could be cleared/overwritten in the repair path, resulting in incomplete or empty arguments passed to tools.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Verified scenarios: Ran the unit tests for the malformed toolCall-arguments repair and confirmed that the final assembled message preserves valid arguments; also confirmed that the “short trailing junk” repair still works. Before the fix, with Kimi in Anthropic-messages streaming mode, multiple consecutive tool_call invocations could carry empty arguments; after the fix, empty-argument tool calls no longer occur.
  • Edge cases checked: -
  • What you did not verify: -

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No): Yes
  • Config/env changes? (Yes/No): No
  • Migration needed? (Yes/No): No
  • If yes, exact upgrade steps: N/A

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: Revert this commit; alternatively disable the Kimi/Anthropic malformed-args repair wrapper if maintainers prefer.
  • Files/config to restore: src/agents/pi-embedded-runner/run/attempt.ts
  • Known bad symptoms reviewers should watch for: Tool calls executed with {}/missing required parameters; intermittent tool failures only on Kimi Anthropic-compatible runs.

Risks and Mitigations

  • Risk: Repair logic might still be triggered too aggressively for some unusual streaming chunk patterns.
    • Mitigation: Keep repair gated to Kimi + anthropic-messages, retain strict trailing-suffix limits, and add/extend unit coverage for representative delta sequences.

Changed files

  • src/agents/pi-embedded-runner/run/attempt.test.ts (modified, +48/-0)
  • src/agents/pi-embedded-runner/run/attempt.ts (modified, +9/-3)

Code Example

Missing required parameter: path alias. Supply correct parameters before retrying.

---

Validation failed for tool "exec": command: must have required property 'command'

---

Validation failed for tool "feishu_drive_file": action: must have required property 'action'

---

[15:16:35] read: Missing required parameter: path alias (×7)
[15:16:42] exec: Missing required property 'command' (×10+)
[15:16:48] feishu_drive_file: Missing required property 'action' (×3)

---

Missing required parameter: path alias. Supply correct parameters before retrying.

---

Validation failed for tool "exec": command: must have required property 'command'

---

Validation failed for tool "feishu_drive_file": action: must have required property 'action'

---
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

name: Bug report about: LLM tool call validation errors when parameters are missing title: '[Bug] Tool calls fail with validation errors when required parameters are omitted' labels: bug, tool-calling, validation assignees: ''

Bug Description

When LLM fails to construct complete parameters during a tool call chain, it repeatedly calls the same tool (passing empty object {} or missing required parameters), resulting in repetitive validation errors. This is not an issue with individual tools, but a flaw in the tool calling mechanism's retry behavior when parameter construction fails.

Environment

ItemVersion/Info
OpenClaw VersionLatest (2026-03-24)
Hostchen's Mac mini
OSDarwin 25.2.0 (arm64)
Node.jsv24.14.0
Modelkimi/kimi-code
Default Modelkimi/kimi-code
Shellzsh
Channelwebchat

Steps to Reproduce

  1. Trigger a task requiring multi-step tool calls
  2. During parameter construction, if LLM fails to properly populate required parameters
  3. Observe the tool being called multiple times (with empty object {})
  4. Each call returns the same validation error

Actual Behavior

Error Type 1: read tool missing path parameter

Missing required parameter: path alias. Supply correct parameters before retrying.
  • Occurrences: 7 times
  • Trigger scenario: Calling read with only empty object {}, without providing file_path or path

Error Type 2: exec tool missing command parameter

Validation failed for tool "exec": command: must have required property 'command'
  • Occurrences: 10+ times
  • Trigger scenario: Calling exec with only empty object {}, without providing command

Error Type 3: feishu_drive_file tool missing action parameter

Validation failed for tool "feishu_drive_file": action: must have required property 'action'
  • Occurrences: 3 times
  • Trigger scenario: Calling feishu_drive_file with only empty object {}, without providing action

Expected Behavior

  1. Pre-validation: System should validate all required parameters are populated before sending tool calls
  2. Single failure: If parameter construction fails, should error only once instead of repeatedly calling the same tool
  3. Friendly hints: Error messages should guide LLM on how to correctly fill missing parameters
  4. Graceful degradation: If parameters cannot be constructed, should stop current tool chain instead of retrying

Root Cause Analysis

The core issues are:

  1. Fallback behavior on parameter construction failure: When LLM cannot correctly construct complex parameters, it may fallback to passing empty object {}
  2. Lack of pre-validation: System does not validate parameter completeness before sending
  3. Over-aggressive retry mechanism: After encountering validation errors, LLM attempts to call again but still uses the same empty parameters

Suggested Fix

Option 1: Client-side Pre-validation (Recommended)

Before sending tool call requests, system layer validates all required parameters exist:

  • If missing, immediately return structured error to LLM instead of sending to tool layer
  • This avoids invalid remote calls

Option 2: Error Feedback Optimization

When detecting empty parameters or missing required parameters:

  • Return more detailed errors containing parameter schema information
  • Prompt LLM which fields need to be filled

Option 3: Retry Limiting

For validation errors (e.g., missing required parameter):

  • Limit retry count to 1
  • Or require LLM to modify parameters before continuing

Additional Context

Complete Error Log Timeline

[15:16:35] read: Missing required parameter: path alias (×7)
[15:16:42] exec: Missing required property 'command' (×10+)
[15:16:48] feishu_drive_file: Missing required property 'action' (×3)

Original User Request

"Send the README.md file to my Feishu cloud drive"

This was a simple request, but triggered multiple tool call errors during execution.

Checklist

  • I have checked existing issues and found no duplicates
  • I have provided reproduction steps and environment information
  • This is not a tool-specific issue, but a tool calling mechanism issue

Steps to reproduce

  1. Trigger a task requiring multi-step tool calls
  2. During parameter construction, if LLM fails to properly populate required parameters
  3. Observe the tool being called multiple times (with empty object {})
  4. Each call returns the same validation error

Expected behavior

  1. Pre-validation: System should validate all required parameters are populated before sending tool calls
  2. Single failure: If parameter construction fails, should error only once instead of repeatedly calling the same tool
  3. Friendly hints: Error messages should guide LLM on how to correctly fill missing parameters
  4. Graceful degradation: If parameters cannot be constructed, should stop current tool chain instead of retrying

Actual behavior

Error Type 1: read tool missing path parameter

Missing required parameter: path alias. Supply correct parameters before retrying.
  • Occurrences: 7 times
  • Trigger scenario: Calling read with only empty object {}, without providing file_path or path

Error Type 2: exec tool missing command parameter

Validation failed for tool "exec": command: must have required property 'command'
  • Occurrences: 10+ times
  • Trigger scenario: Calling exec with only empty object {}, without providing command

Error Type 3: feishu_drive_file tool missing action parameter

Validation failed for tool "feishu_drive_file": action: must have required property 'action'
  • Occurrences: 3 times
  • Trigger scenario: Calling feishu_drive_file with only empty object {}, without providing action

OpenClaw version

2026-03-24

Operating system

macOS Darwin 25.2.0

Install method

npm

Model

kimi/kimi-code

Provider / routing chain

openclaw-> kimi/kimi-code

Additional provider/model setup details

<img width="660" height="804" alt="Image" src="https://github.com/user-attachments/assets/26701ab2-5a52-48cc-9aea-13c852583d75" />

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

Fix Plan

To address the issue of repetitive validation errors due to missing required parameters in tool calls, we will implement a client-side pre-validation mechanism. This approach ensures that all required parameters are populated before sending tool call requests.

Step 1: Define Required Parameters

Identify and document all required parameters for each tool. This can be done by reviewing the tool's API documentation or source code.

Step 2: Implement Pre-validation

Create a function that checks if all required parameters are present before making a tool call. If any parameter is missing, return an error message indicating which parameters need to be filled.

function validateToolCall(toolName, parameters) {
  const requiredParameters = getRequiredParameters(toolName);
  for (const parameter of requiredParameters) {
    if (!parameters[parameter]) {
      return `Missing required parameter: ${parameter}`;
    }
  }
  return null; // No errors found
}

function getRequiredParameters(toolName) {
  // Return an array of required parameters for the given tool
  // This can be implemented as a lookup table or a database query
  // For example:
  const requiredParameters = {
    'read': ['path'],
    'exec': ['command'],
    'feishu_drive_file': ['action']
  };
  return requiredParameters[toolName];
}

Step 3: Integrate Pre-validation with Tool Calls

Modify the tool call mechanism to include the pre-validation step. If the pre-validation fails, display a friendly error message to the user and stop the tool chain.

function makeToolCall(toolName, parameters) {
  const errorMessage = validateToolCall(toolName, parameters);
  if (errorMessage) {
    console.error(errorMessage);
    return; // Stop the tool chain
  }
  // Proceed with the tool call
  // ...
}

Verification

To verify that the fix worked, test the tool call mechanism with different scenarios, including:

  • Valid parameters: The tool call should succeed without any errors.
  • Missing required parameters: The pre-validation should catch the error and display a friendly error message.
  • Invalid parameters: The tool call should fail with an error message indicating the invalid parameter.

Extra Tips

  • Make sure to document the required parameters for each tool and keep the documentation up-to-date.
  • Consider implementing a retry mechanism with a limited number of retries to handle temporary errors.
  • Use a consistent error handling mechanism throughout the tool call chain to ensure that errors are properly propagated and displayed to the user.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

  1. Pre-validation: System should validate all required parameters are populated before sending tool calls
  2. Single failure: If parameter construction fails, should error only once instead of repeatedly calling the same tool
  3. Friendly hints: Error messages should guide LLM on how to correctly fill missing parameters
  4. Graceful degradation: If parameters cannot be constructed, should stop current tool chain instead of retrying
#optimization#API rate limit#retriever error#indexing error#inference speed

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING