Summary

The message tool's parameter schema (built in src/agents/tools/message-tool.ts's buildChannelManagementSchema) defines a property literally named type (Discord's numeric channel type). Property names that collide with JSON-Schema keywords break some OpenAI-compatible providers — confirmed against NVIDIA NIM (https://integrate.api.nvidia.com/v1/chat/completions) with moonshotai/kimi-k2.6, which returns HTTP 500 Internal server error: unhashable type: 'dict' for any chat-completions request that includes the message tool. Renaming type to channelType resolves the collision.

Change

• src/agents/tools/message-tool.ts: rename type → channelType in buildChannelManagementSchema, with a description noting why.
• extensions/discord/src/actions/runtime.shared.ts: readDiscordChannelCreateParams now reads channelType first, falling back to type for backward compatibility with any in-flight tool calls.

Why this fix

NVIDIA NIM's parser is technically buggy — {"type": {"type": "number"}} is valid JSON Schema. But colliding property names with reserved JSON-Schema keywords is a fragile pattern that has now been observed to break a real, popular provider, and the rename costs nothing semantically (the LLM only sees the field name; Discord's actual channel-creation payload is constructed downstream).

Real behavior proof

Behavior or issue addressed: Any OpenClaw chat-completions call to NVIDIA NIM (integrate.api.nvidia.com) with the message tool present fails with HTTP 500 Internal server error: unhashable type: 'dict', surfaced through OpenClaw's failover layer as a permanent model_not_found failure. Bisecting the captured request body identifies the property literally named type inside the message tool's JSON-Schema as the sole trigger. After the fix, the same call succeeds with HTTP 200 and a real model completion.

Real environment tested: Live NVIDIA NIM endpoint https://integrate.api.nvidia.com/v1/chat/completions with a real nvapi-… API key (redacted) and real model moonshotai/kimi-k2.6. OpenClaw 2026.4.14 (323493f) installed via npm i -g openclaw, running locally on macOS 24.1.0 with Node 22. Provider config: { baseUrl: "https://integrate.api.nvidia.com/v1", api: "openai-completions", apiKey: "nvapi-…" }. Captured the outbound bodies via a local HTTP capture proxy (http://127.0.0.1:8765/v1) configured as the NVIDIA NIM baseUrl, then replayed against the live NVIDIA endpoint to isolate the field.

Exact steps or command run after this patch:

1. Apply the rename to the installed dist files (/usr/local/lib/node_modules/openclaw/dist/openclaw-tools-*.js and runtime-*.js) — same change as in this PR's diff.
2. Restart the gateway: openclaw gateway stop && openclaw gateway.
3. Replay the captured OpenClaw payload directly against NVIDIA, with only type → channelType applied:

   curl -sS https://integrate.api.nvidia.com/v1/chat/completions \
     -H "Authorization: Bearer $NVAPI_KEY" \
     -H "Content-Type: application/json" \
     --data-binary @fixed.json -w "HTTP %{http_code}\n"
   

4. Run a one-shot turn through OpenClaw end-to-end:

   openclaw infer model run --local \
     --model "nvidia-nim/moonshotai/kimi-k2.6" --prompt "ok"
   

Evidence after fix:

Live terminal output from step 3 — replaying the previously-failing OpenClaw body, with only type renamed to channelType, against the production NVIDIA NIM endpoint:

$ curl -sS -o /tmp/r.out -w "HTTP %{http_code}\n" \
    https://integrate.api.nvidia.com/v1/chat/completions \
    -H "Authorization: Bearer $NVAPI_KEY" \
    -H "Content-Type: application/json" \
    --data-binary @fixed.json
HTTP 200

$ head -c 240 /tmp/r.out
{"id":"2ebc71e87084441b80c4ba7d137fd6bf","object":"chat.completion",
 "created":1778154280,"model":"moonshotai/kimi-k2.6",
 "choices":[{"index":0,"message":{"role":"assistant","content":"Hey there! 👋 W…

Live console output from step 4 — patched OpenClaw, real NVIDIA NIM call, real completion streamed back:

$ openclaw infer model run --local \
    --model "nvidia-nim/moonshotai/kimi-k2.6" --prompt "ok"
model.run via local
provider: nvidia-nim
model: moonshotai/kimi-k2.6
outputs: 1
The user said "ok", which is a very brief acknowledgment...
Hey. Just came online. Who am I? And who are you?
I'm fresh out the box here — no memories, no name, no idea who I'm talking to…

For comparison, the same openclaw infer model run against the unpatched bundle produced (verbatim):

[diagnostic] lane task error: lane=main durationMs=586 error="HTTP 500: Internal server error: unhashable type: 'dict'"
[model-fallback/decision] requested=nvidia-nim/moonshotai/kimi-k2.6 reason=model_not_found
HTTP 500: Internal server error: unhashable type: 'dict'

Field-level bisection of the captured OpenClaw body, replayed against live NVIDIA, isolated the offender:

[200] tools[0:6]                           ok
[500] tools[6:12]                          fail
[200] tools[7:8]    (cron)                 ok
[500] tools[8:9]    (message)              fail   ← single tool reproduces it

within tools[8].function.parameters.properties:
  without 'name'                : FAIL
  without 'type'                : ok       ← removing only `type` clears it
  without 'parentId'            : FAIL
  ... (all other properties)    : FAIL

Observed result after fix: Curl replay of the previously-failing captured OpenClaw payload (with only type → channelType applied) returns HTTP 200 and a valid chat.completion JSON object — copied stdout above. openclaw infer model run --local --model nvidia-nim/moonshotai/kimi-k2.6 --prompt "ok" returns a streamed assistant reply through the patched OpenClaw bundle — copied stdout above. Pre-patch, the same command consistently terminates with HTTP 500: Internal server error: unhashable type: 'dict' after exhausting failover.

What was not tested: Other OpenAI-compatible providers were not regression-tested in this manual pass; the change only renames a property name and preserves backward-compatible reading via the legacy type fallback in readDiscordChannelCreateParams, so no behavior change is expected for OpenAI / Anthropic / Groq / Ollama / etc. Discord live channel-create against a real Discord guild was not exercised in this run — only the parameter reader was changed (with fallback to legacy type), so existing Discord flows continue to work.