zai-coding-plan: build gets 400 when Dokploy MCP tools are enabled

Summary

zai-coding-plan/glm-5.3 returns HTTP 400 (Invalid API parameter, please check the documentation.) for the build agent when the Dokploy MCP server is enabled. The same model and account work with a direct request to Z.AI's Coding Plan endpoint.

Environment

• OpenCode 1.18.15
• provider: zai-coding-plan
• runtime: ai-sdk / @ai-sdk/openai-compatible
• model: glm-5.3 (also reproduced with glm-5-turbo)
• MCP: Dokploy enabled (other MCP servers were present during the original failure)

Reproduction / evidence

1. A direct POST https://api.z.ai/api/coding/paas/v4/chat/completions with model, messages, and stream:false returns 200 for glm-5.3 and glm-5-turbo.
2. In a fresh OpenCode session, the title request succeeds but the following build request fails with 400.
3. I captured the outgoing request by overriding only the model catalog API URL to a localhost recorder. No Authorization header or prompt text was retained.

The failing build request has this shape:

{
  "model": "glm-5.3",
  "max_tokens": 32000,
  "thinking": { "type": "enabled", "clear_thinking": false },
  "tool_choice": "auto",
  "tools": "641 function definitions (~337 KB)",
  "stream": true,
  "stream_options": { "include_usage": true }
}

It is not tools: [] combined with tool_choice: "required".

The title request has no tools and succeeds. The following combinations independently return HTTP 200 against Z.AI:

• thinking only;
• one neutral function with tool_choice: "auto";
• thinking + one neutral function;
• 641 synthetic functions, including Draft 2020 schemas and anyOf;
• a synthetic tool payload larger than the captured request.

The decisive isolation is running the same OpenCode binary and model with an empty XDG config (no MCP): build returns OK. Re-enabling Dokploy MCP reproduces the failure.

Expected behavior

Either the request should succeed with Dokploy MCP enabled, or OpenCode should provide a way to exclude/filter MCP tools per provider/model so an OpenAI-compatible provider with stricter function-schema compatibility can still be used.

Possible direction

The failure appears to be a particular real Dokploy MCP schema (or combination of its schemas), rather than generic tool count, tool payload size, thinking, or tool_choice. A per-provider tool filtering/capability mechanism, and/or a clear diagnostic exposing the rejected tool/schema, would make this debuggable without having to disable all MCP integrations.