Model declared without capabilities: an image-returning MCP tool aborts the run mid-task, after side effects, with no hint at the fix

Summary

When a model is declared in config.toml without capabilities, and an MCP tool returns an image, the run is aborted after the tool has already run and had its side effects — and the error does not say what to add to fix it.

Repro

config.toml for an OpenAI-compatible endpoint (a self-hosted vLLM serving a vision-capable model under a local alias):

[providers.local]
type = "openai_legacy"
base_url = "http://localhost:8020/v1"
api_key = "EMPTY"

[models.local]
provider = "local"
model = "Qwen3.6-27B"
max_context_size = 262144

[config]
default_model = "local"

Then run non-interactively with an MCP server whose tool returns a screenshot:

kimi --print --afk --yolo --config-file config.toml --mcp-config-file mcp.json \
     --model local --prompt "<task that edits a document, then screenshots it to verify>"

The agent calls the editing tools successfully, then calls the screenshot tool, and the run ends:

StepInterrupted()
LLM model 'Qwen3.6-27B' does not support required capability: image_in.

with exit code 1.

What is wrong with this

check_message() computes the missing capabilities and the step is interrupted. That is correct in itself, but:

1. It happens after side effects. The document had already been modified by earlier tool calls. The session ends with the work done but unreported — from the caller's perspective the task simply failed. A capability that is statically knowable (the model config, and the fact that the mounted MCP server declares an image-returning tool) takes the run down mid-flight.
2. The error does not name the remedy. capabilities = ["image_in"] on [models.<alias>] is exactly the fix, and the message never mentions it. Docs do describe the field, but the failing user is reading this error, not the docs.
3. Auto-detection quietly does not apply here. Capabilities are matched by model-name prefix, which cannot work for a model served under a local alias through a self-hosted gateway — a first-class use case for openai_legacy. The model is vision-capable (posting image_url content to the same endpoint directly returns a normal answer); only kimi's view of it is empty.

Suggestions (any one of these would have saved the run)

• Validate at startup: if the mounted tools can return images/video and the selected model declares no matching capability, warn (or fail fast) before the agent starts doing work.
• Degrade instead of aborting: drop the unsupported part, hand the model a short text note ("screenshot omitted: model has no image_in"), and let the turn continue.
• Include the fix in the error text: add capabilities = ["image_in"] to [models.<alias>].

Version

kimi-cli 1.49.0 (installed via uv tool install --python 3.13 kimi-cli), Linux, Python 3.13.

Adding capabilities = ["image_in", "thinking"] to the model alias resolves it completely — the same run then completes with the screenshot used normally. Filing because the failure mode (abort after side effects, no remedy in the message) seems worth smoothing rather than the config itself.

Start at check_message() and the model capability configuration used by the provided config.toml and MCP command. Reproduce the image-returning tool flow with the shown non-interactive command, then trace where the unsupported capability interrupts the step. Done should prevent an unexplained mid-task failure or include the actionable capabilities configuration fix; the preferred behavior needs maintainer confirmation.