#Kimi: Tool Validation Error: kimi-coding/k2p5: raistlin28

1 messages · Page 1 of 1 (latest)

frank lynx
#

OpenClaw Support: kimi-coding/k2p5 Tool Validation Error — Diagnostic Report

1. Summary

After upgrading from a custom kimi-code provider (using openai-completions adapter) to the built-in kimi-coding provider (using anthropic-messages adapter) per the guidance in Issue #22409 / PR #22526, all tool-using agent interactions fail with 23 validation errors. The Kimi Coding API endpoint rejects tool definitions sent in Anthropic format, expecting OpenAI format instead.

Pure text chat (no tools) works correctly on kimi-coding/k2p5 with anthropic-messages.

2. Error Message (verbatim, truncated)

[Error: request could not be processed] {
  "error": {
    "message": "23 validation errors:\n
      {'type': 'missing', 'loc': ('body', 'tools', 0, 'function'), 'msg': 'Field required',
       'input': {'name': 'read', 'description': 'Read the contents of a file. Supports text files and images (jpg, png, gif, webp). Images are sent as attachments. For text files, output is truncated to 2000 lines or 50KB (whichever is hit first). Use offset/limit for large files. When you need the full file, continue with offset until complete.',
       'input_schema': {'type': ...

All 23 built-in tools (read, exec, web_search, cron, etc.) produce identical validation errors. Each error says 'function' field is required at body.tools[N].

3. Environment & Configuration

3.1 OpenClaw Version

meta.lastTouchedVersion: "2026.2.26"
wizard.lastRunVersion: "2026.2.26"
wizard.lastRunCommand: "doctor"
wizard.lastRunMode: "local"
frosty matrixBOT
#

That error is pretty unambiguous: the upstream endpoint is validating tools[] as OpenAI function tools (tools[n].function required), but OpenClaw’s anthropic-messages adapter is sending Anthropic tool definitions ({ name, description, input_schema }). So the Kimi Coding endpoint you’re hitting is “Anthropic-compatible” for plain messages, but not Anthropic-compatible for tools (at least not with the current tool schema).

What I’d do next (quick confirmation)

  1. Paste openclaw --version (the meta.lastTouchedVersion helps, but we need the actual binary version).
  2. From openclaw logs --follow, grab the line that shows the request URL/path for the Kimi call (even just whether it’s hitting something like /v1/messages vs an OpenAI-style endpoint). That will confirm whether this is:
    • OpenClaw pointing at the wrong base URL, or
    • Kimi’s endpoint mixing “Anthropic messages” with “OpenAI tools” validation.

Workarounds (today)

  • Use your previous custom provider config (the one using openai-completions) if it worked. Given the validation error, that’s the schema this endpoint wants for tool use right now.
  • If you also have a Moonshot key, use the documented Moonshot OpenAI-compatible provider (moonshot/*) instead of kimi-coding/* (docs: https://docs.openclaw.ai/providers/moonshot and https://docs.openclaw.ai/concepts/model-providers). That path is explicitly OpenAI-compatible and tends to behave better with tools.

Upstream fix (likely needed)

Either:

  • OpenClaw’s built-in kimi-coding provider needs to translate tool definitions into OpenAI’s {type:"function", function:{...}} shape, or
  • The provider should not be using the anthropic-messages adapter if the endpoint expects OpenAI tool schema, or
  • Kimi needs to fix their “Anthropic-compatible” endpoint to accept Anthropic tool definitions.
#

If you haven’t already, this is 100% “file a GitHub issue with your report + a few log lines showing the request path/baseUrl” territory: https://github.com/openclaw/openclaw/issues (your diagnostic writeup is already basically the issue body).

If you drop openclaw --version + the request URL/path from logs, I can tell you which of the three buckets it falls into.

frank lynx
#

3.2 Provider Configuration (openclaw.json)

No custom kimi-coding provider is defined in models.providers. The config relies entirely on the built-in provider via models.mode: "merge":

{
  "models": {
    "mode": "merge",
    "providers": {
      "openrouter": { "api": "openai-completions", ... },
      "zai": { "api": "openai-completions", ... },
      "openai-codex": { "api": "openai-responses", ... }
    }
  }
}

The kimi-coding provider is NOT listed in models.providers — it is resolved from OpenClaw's built-in provider registry.

3.3 Auth Profile

{
  "auth": {
    "profiles": {
      "kimi-coding:default": {
        "provider": "kimi-coding",
        "mode": "api_key"
      }
    },
    "order": {
      "kimi-coding": ["kimi-coding:default"]
    }
  }
}

3.4 Agent Configuration (affected agent)

{
  "id": "raistlin",
  "name": "Donna",
  "workspace": "<redacted>",
  "model": {
    "primary": "kimi-coding/k2p5",
    "fallbacks": ["openai-codex/gpt-5.4"]
  }
}

3.5 Global Defaults

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "kimi-coding/k2p5",
        "fallbacks": ["kimi-coding/k2p5", "openai-codex/gpt-5.4"]
      },
      "thinkingDefault": "medium"
    }
  }
}

3.6 Per-Agent Derived Cache

The file ~/.openclaw/agents/raistlin/agent/models.json was regenerated on 2026-03-06 06:58 +0800 and contains:

{
  "providers": {
    "kimi-coding": {
      "baseUrl": "https://api.kimi.com/coding/",
      "api": "anthropic-messages",
      "models": [
        {
          "id": "k2p5",
          "name": "Kimi for Coding",
          "reasoning": true,
          "input": ["text", "image"],
          "contextWindow": 262144,
          "maxTokens": 32768
        }
      ],
      "apiKey": "<redacted>"
    }
  }
}

Note: "api": "anthropic-messages" — this matches the fix from PR #22526.

#

3.7 Shipped Runtime Confirmation

The distributed runtime binary also hardcodes kimi-coding as anthropic-messages:

  • dist/auth-token-xKTlRWep.js line 776: kimi-coding provider template with api: "anthropic-messages"
  • dist/auth-token-xKTlRWep.js line 801: same

4. Reproduction Steps

  1. Install OpenClaw 2026.2.26 on macOS
  2. Configure kimi-coding:default auth profile with valid API key
  3. Set any agent's primary model to kimi-coding/k2p5
  4. Set agents.defaults.thinkingDefault to "medium" (or any non-null value)
  5. Do NOT define a custom kimi-coding provider in models.providers (rely on built-in)
  6. Send any message that triggers tool use (e.g., a cron job that reads a file, or an interactive message where the agent invokes read, exec, web_search, etc.)
  7. Result: 23 validation errors — every tool definition rejected

Minimal reproduction via cron

A cron job with a prompt containing Read MEMORY.md and summarize will trigger the read tool, producing the error immediately.

5. What Works vs What Fails

Scenario Model Adapter Tools Present Result
Text-only chat (no tools triggered) kimi-coding/k2p5 anthropic-messages No Works
Cron with tool-using prompt kimi-coding/k2p5 anthropic-messages Yes (23 tools) FAILS — 23 validation errors
Same cron, same prompt kimi-code/kimi-for-coding (old custom) openai-completions Yes Worked (before migration)
Same agent, fallback model openai-codex/gpt-5.4 openai-responses Yes Works
Different provider, same tools openrouter/* openai-completions Yes Works
#

6. Root Cause Analysis

6.1 The Adapter Format Mismatch

The anthropic-messages adapter formats tool definitions in Anthropic SDK style:

{
  "name": "read",
  "description": "Read the contents of a file...",
  "input_schema": {
    "type": "object",
    "properties": { ... }
  }
}

The Kimi Coding API endpoint at https://api.kimi.com/coding/ validates tool definitions against the OpenAI schema, which expects:

{
  "type": "function",
  "function": {
    "name": "read",
    "description": "Read the contents of a file...",
    "parameters": {
      "type": "object",
      "properties": { ... }
    }
  }
}

The validation error 'loc': ('body', 'tools', 0, 'function'), 'msg': 'Field required' confirms the endpoint expects the function wrapper object but receives a flat Anthropic-style tool definition.

6.2 Hybrid API Behaviour

The Kimi Coding API appears to be a hybrid endpoint:

  • Messages/streaming: Accepts and returns Anthropic-format SSE events (content_block_start, content_block_delta, etc.)
  • Tool definitions: Validates against OpenAI schema (requires type: "function" wrapper)

This means neither adapter is fully correct:

  • anthropic-messages: Correct for streaming, incorrect for tool definitions
  • openai-completions: Correct for tool definitions, incorrect for streaming (produces SSE event-ordering bugs — content_block_stop before message_start)

6.3 Compounding Factor: Thinking + Tool Use

Global config sets thinkingDefault: "medium" and per-agent cache has reasoning: true for k2p5. Per GitHub Issue #16952 (OPEN, unfixed), the anthropic-messages adapter also fails on multi-turn conversations with thinking + tool_use, producing: "thinking is enabled but reasoning_content is missing in assistant tool call message". This is a secondary failure mode that would trigger even if the tool definition format were corrected.

#

8. Prior Working State

Before the migration (pre-2026-03-06), a custom provider was defined:

{
  "kimi-code": {
    "baseUrl": "https://api.kimi.com/coding/v1",
    "api": "openai-completions",
    "models": [
      {
        "id": "kimi-for-coding",
        "name": "Kimi For Coding",
        "reasoning": true,
        "input": ["text", "image"],
        "contextWindow": 262144,
        "maxTokens": 32768,
        "headers": { "User-Agent": "KimiCLI/0.77" },
        "compat": { "supportsDeveloperRole": false },
        "api": "openai-completions"
      }
    ]
  }
}

This custom provider used openai-completions, which correctly formatted tool definitions with the function wrapper. Tool-using crons worked. However, SSE streaming had intermittent event-ordering bugs (Unexpected event order errors), which is why the migration to the built-in anthropic-messages provider was performed.

Session evidence of prior working state: session bf721695-7b90-4266-98bc-34415d2e5796 (same cron, same prompt, same agent, tools succeeded on kimi-for-coding + openai-completions).

frosty matrixBOT
#

Yep — that extra detail (the derived models.json) basically proves it’s not a local config mixup:

  • Built-in provider resolves to
    baseUrl: https://api.kimi.com/coding/ + api: anthropic-messages
  • And the upstream response is validating body.tools[*].function (OpenAI-style tool schema), while OpenClaw is sending Anthropic-style tools ({ name, description, input_schema }).

So the Kimi “Claude Code / Anthropic-compatible” endpoint is not accepting Anthropic tool definitions (even though it accepts plain text in Anthropic Messages format). That’s consistent with exactly what you’re seeing: chat works, any tool call fails immediately at request validation.

Two useful references to include in the upstream ticket:

Practical workaround (until OpenClaw or Kimi fixes tool compatibility)

Use the OpenAI-compatible entrypoint (…/coding/v1) with an openai-completions-style provider (i.e., go back to your previous custom kimi-code provider setup that was working for tools). The built-in kimi-coding provider path (anthropic-messages + …/coding/) currently can’t do tools if the server insists on tools[].function.

#

What I’d ask you for to make the GitHub issue airtight

  1. openclaw --version output (actual binary version; the meta.lastTouchedVersion is helpful but not definitive).
  2. A snippet of the actual outgoing request body logged (or “debug request” line) showing tools: [{ name, description, input_schema: …}] right before the error, plus the URL it POSTs to (should end up at something like /coding/v1/messages).

If you file a new issue (or comment on the existing one), paste the “tools[].function required” validation error plus that derived provider cache snippet — that’s the smoking gun that the endpoint is enforcing OpenAI tool schema on the Anthropic Messages route.

frank lynx
#

OpenClaw version 2026.3.2

frosty matrixBOT
#

This is about as “proven” as it gets now:

  • Your agent-derived cache shows OpenClaw is correctly using Kimi’s Claude Code endpoint (https://api.kimi.com/coding/) with api: "anthropic-messages".
  • The upstream error is still validating tool defs as OpenAI tools (tools[n].function required).

So at this point it’s not a mis-merge, not “doctor overwrote my config”, and not you accidentally pointing at /coding/v1. It’s either:

  1. Kimi bug / incomplete Anthropic compatibility for tools (they accept Messages, but their tool validator is the OpenAI one), or
  2. OpenClaw bug (we’re sending a tools payload shape Kimi’s Anthropic-compat endpoint doesn’t accept, even though Claude Code does), which would imply Claude Code is sending a different tool schema than “vanilla Anthropic tools”.

What you can do right now (pragmatic workaround)

Use the OpenAI-compatible Kimi integration for any workflow that needs tools (cron, file read, exec, web_search), i.e. go back to your working openai-completions provider setup against https://api.kimi.com/coding/v1 (Roo Code-style). Keep kimi-coding/k2p5 for text-only if you want, but don’t route tool runs to it until this is fixed.

(Also: in your global defaults you have fallbacks: ["kimi-coding/k2p5", "openai-codex/gpt-5.4"] — the duplicate first fallback just burns time when Kimi errors. Worth removing so it fails over immediately.)

What should happen upstream

This needs a GitHub issue specifically framed as:

#
  • kimi-coding uses anthropic-messages + https://api.kimi.com/coding/ per Kimi docs
  • Any request that includes tools fails because Kimi validates tools as OpenAI (tools[].function)
  • Therefore OpenClaw needs either:
    • a Kimi-specific tool schema translation, or
    • different adapter for this provider, or
    • Kimi needs to fix their endpoint to accept Anthropic tool definitions.

You already have everything needed for the issue body. The only “missing” piece that would make it bulletproof is the exact request URL + minimal JSON body from logs (redacting keys), plus openclaw --version.

If you post the GitHub issue link here after filing, I can help tighten the title/repro/expected-vs-actual so it’s maximally actionable for whoever picks it up.

#

Your RCA tracks with what the error is telling you, and the extra “hybrid” observations are especially useful:

  • Endpoint: https://api.kimi.com/coding/ is the Claude Code / Anthropic-compatible base URL per Kimi’s docs.
  • Streaming: looks Anthropic-ish (SSE blocks like content_block_*).
  • Tools: validator is clearly expecting OpenAI function-tool objects (tools[n].function), not Anthropic’s { name, description, input_schema }.

So yeah: as implemented today, it behaves like a hybrid protocol — and OpenClaw currently assumes “anthropic-messages” implies Anthropic tool schema.

How I’d suggest you proceed (so this actually gets fixed)

  1. File a new OpenClaw issue focused on the primary breakage: “Kimi Coding Anthropic endpoint rejects Anthropic tool definitions; expects OpenAI function tools”.

  2. Link (but don’t bundle) the thinking/tool_use bug as a secondary, separate OpenClaw problem:

    • Issue #16952 (“thinking is enabled but reasoning_content is missing…”) is real and would likely bite you right after tools start working.
    • Practical mitigation for that is simply setting thinking to off for these runs (either /think:off per-session or agents.defaults.thinkingDefault: "off" globally). Source: docs/tools/thinking.md in-repo.
#

Keeping them separate in tracking matters, because:

  • the tool schema mismatch is a Kimi-provider/adapter compatibility problem (or a Kimi endpoint bug),
  • while #16952 is OpenClaw’s Anthropic message serialization across tool turns.

Workaround right now

Until the tool schema issue is fixed, the only working path for “tools + Kimi” is still the OpenAI-compatible route (…/coding/v1 + openai-completions), because that’s the schema the validator is enforcing.

If you post the GitHub issue link once you open it, I can help tighten the “expected vs actual” section and propose the most likely fix direction (e.g. a Kimi-specific tool-schema translation inside the anthropic-messages adapter, or a provider-level flag to select the tool schema).

#

That “prior working state” snippet is actually really useful, because it gives you a practical escape hatch that doesn’t require waiting for a new adapter:

1) You can likely keep the old OpenAI-compatible provider and kill the streaming flakiness

You migrated mainly because of SSE “Unexpected event order” issues. In current OpenClaw, there’s a per-model knob in the allowlist to disable upstream streaming:

  • Config schema supports: agents.defaults.models["provider/model"].streaming: false
    (see src/config/zod-schema.agent-defaults.ts — each allowlist entry can include streaming: boolean)

So the most stable workaround is:

  • keep your working kimi-code provider (openai-completions + https://api.kimi.com/coding/v1) for tool runs
  • set the allowlist entry for that model to streaming: false so OpenClaw does non-streaming requests (avoids Kimi’s wonky SSE ordering)

That gets you back to “tools work” without the streaming parser pain.

2) Your model-level headers + compat.supportsDeveloperRole were valid

Worth calling out: OpenClaw does support model-level headers and compat inside models.providers.<id>.models[] (see src/config/types.models.ts), so the User-Agent: KimiCLI/0.77 detail is not “noise” — it may have been part of why the endpoint behaved.

#

3) For the built-in kimi-coding path, this still looks like an upstream/protocol mismatch

Even if tool schema got fixed, you’re right that thinking + tool_use has its own known failure mode in OpenClaw (#16952). So in the issue(s), I’d strongly recommend:

  • Issue A (new): Kimi Coding Anthropic endpoint expects OpenAI tool schema (tools[].function)
  • Issue B (existing #16952): thinking + tool_use serialization bug (workaround: /think:off or agents.defaults.thinkingDefault: "off")

If you want, paste the minimal config snippet you’d use for “old provider + streaming:false” and I’ll sanity-check it against the current schema so you don’t fight config quirks while you wait on upstream fixes.