kimi-cu的兼容bug

你运行的 Kimi Code 版本是？

0.37.2

你使用的是哪个开放平台/订阅？

Kimi Code (OAuth)

你使用的是哪个模型？

grok4.6 k3-256k

你的电脑平台是？

x64

你遇到了什么问题？

kimi-cu-win 的 MCP schema 根是 oneOf；openai_responses 要求 function parameters 根必须是 object；kimi-code 原样转发，整轮 400。

Documented in kimi-cu-win skill (plugins/managed/kimi-cu-win/skills/kimi-cu/SKILL.md):

Target get_app_state with pid, app, or window_id.

That maps naturally to an MCP inputSchema whose root is oneOf/anyOf of three object branches, not a single { "type": "object", "properties": ... }.

This is legal MCP / JSON Schema. It is not legal for OpenAI function calling / Responses tools, which require:

JSON

{
"type": "object",
"properties": { ... },
"required": [ ... ]
}
OpenAI (and compatible gateways) do not accept a root-level oneOf/anyOf unless the root still declares type: "object".

Typical offending shape (reconstructed from the error + plugin docs; not dumped from a live MCP tools/list):

JSON

{
"oneOf": [
{
"type": "object",
"properties": { "pid": { "type": "integer" } },
"required": ["pid"]
},
{
"type": "object",
"properties": { "app": { "type": "string" } },
"required": ["app"]
},
{
"type": "object",
"properties": { "window_id": { "type": "string" } },
"required": ["window_id"]
}
]
}
Error names activate_window first; other tools in the same plugin almost certainly share the same targeting union and would fail next if this one were filtered out.

Enabled tools from kimi.plugin.json:

list_apps, launch_app, activate_window, get_app_state, click, type_text, press_key, scroll, set_value, perform_secondary_action, select_text, drag, turn_ended

Reproduction
Install / enable managed plugin kimi-cu-win so MCP server win is connected.

Configure a custom provider:

Toml

[providers.grok]
type = "openai_responses"
base_url = "https:///v1"
api_key = ""

[models."grok/grok-4.6"]
provider = "grok"
model = "grok-4.6"
max_context_size = 500000
capabilities = ["tool_use", "thinking"]
Start a session on grok/grok-4.6.

Send any user message (no GUI / computer-use request needed).

Result: HTTP 400, turn aborted, error above.

Control: same machine, same MCP plugins, switch to type = "openai" (chat completions) or anthropic / kimi → request succeeds.

Workaround that confirms the tool list is the trigger:

Toml

[tools]
disabled = ["mcp__plugin-kimi-cu-win_win__*"]
After /reload, the openai_responses model works again. Desktop control is then unavailable.

Disabling only activate_window is not sufficient: get_app_state and other targeting tools use the same union.

Isolation
Hypothesis Result
Bad API key / quota No. Same key works after disabling the plugin tools.
Grok / third-party gateway unique bug Unlikely. Error text is the standard Responses/function-schema check (tool parameter root must be an object type). Any strict Responses implementation will reject this.
User invoked a bad tool call No. Failure happens atrequest construction / tool schema validation, before any tool execution.
Onlyactivate_window No. Root cause is schema shape; several tools in the same plugin share it.
kimi-cu-win MCP is “wrong” Debatable. Schema is valid MCP. Theclient converterforopenai_responsesmust not assume MCPinputSchemaalready matches OpenAI function-tool constraints.

Root cause (client-side)
In the openai_responses tool adapter, MCP inputSchema is copied into tools[].parameters without a compatibility pass.

Missing checks / transforms:

If schema root is oneOf / anyOf / allOf and does not have "type": "object", wrap or flatten before send.

If a tool cannot be represented as an OpenAI function schema, drop it from this request and log a warning, instead of 400-ing the whole turn.

Prefer not to fail closed on the first incompatible MCP tool when the user is not even using computer-use.

This only shows up on openai_responses because that protocol’s function-tool JSON Schema is stricter than Anthropic tools / Kimi native tools / many Chat Completions gateways.

Suggested fix (in order of preference)
A. Normalize in the openai_responses adapter (recommended, one place)

When converting MCP → Responses function tools:

If root has oneOf/anyOf of object branches: either

wrap: { "type": "object", "oneOf": [...] }, or

flatten to a single object with optional properties + description “pass exactly one of …”, which is more widely accepted.

If a schema still cannot be expressed, omit that tool and warn:
skipping MCP tool X: parameters root is not type=object.

B. Harden kimi-cu-win schemas (plugin-side, still worth doing)

Change targeting tools from root oneOf to:

JSON

{
"type": "object",
"properties": {
"pid": { "type": "integer" },
"app": { "type": "string" },
"window_id": { "type": "string" }
},
"additionalProperties": false
}
Keep “exactly one of pid/app/window_id” in the tool description (runtime can still 400 if zero/many are set). That is compatible with OpenAI, Anthropic, and Kimi.

C. Fail soft

Even without a perfect conversion, never let one MCP tool schema take down every openai_responses session. Filter + warn.

A + C together is the robust fix: official plugin + any third-party MCP with union schemas.

Impact
Any Windows user with kimi-cu-win enabled cannot use custom openai_responses providers (GPT-via-Responses, Grok-via-Responses, OpenAI-compatible gateways).

Failure is total: not “computer use broken”, but the coding agent cannot talk to the model at all.

Official managed plugin + documented provider type, so this is a first-party compatibility bug, not a user misconfig.

Workaround (user-side, already applied)
Toml

[tools]
disabled = ["mcp__plugin-kimi-cu-win_win__*"]
Then /reload. Restores openai_responses models; disables Windows computer-use.

Request
Please treat this as:

Client bug in MCP → openai_responses function-tool conversion (must normalize or skip non-object-root schemas).

Plugin hygiene in kimi-cu-win: prefer type: "object" roots for all tools, even if MCP allows unions.

Happy to attach a redacted request dump / tools/list schema if you have a debug flag for “log serialized Responses tools payload”.

Inspect the openai_responses MCP-to-function-tool adapter and the schemas described in plugins/managed/kimi-cu-win/skills/kimi-cu/SKILL.md and kimi.plugin.json. Reproduce with the kimi-cu-win plugin and an openai_responses provider, then verify that incompatible tool schemas no longer abort the whole request and that the affected tools are handled with an appropriate warning.