Bug: Configuring any MCP server crashes Maka: native capability provider requires zod tool.parameters but buildMcpTools uses ai.jsonSchema() (plain object)

[ser163]

Bug Report: Configuring any MCP server crashes Maka (native capability provider requires tool.parameters instanceof z.ZodType, but buildMcpTools wraps schemas with ai.jsonSchema() which returns a plain object)

---

Summary

Adding any stdio MCP server to the workspace mcp.json crashes Maka at startup / takes the runtime-host down. The desktop app becomes unusable (all IPC hangs, execution-candidate-main.js cannot stay connected) until mcpServers is cleared. This affects every MCP server, not a specific one — MCP support is effectively broken in 0.2.0.

Environment

• App: Maka desktop 0.2.0 (packaged macOS, arm64; CHANGELOG marks 0.2.0 as "Unreleased")
• Electron 43.4.1 / Node 24.18.1
• macOS 26.6
• Trigger: any stdio MCP server (e.g. a 15-line server returning one tool with a JSON-Schema input) registered in ~/Library/Application Support/Maka/workspaces/default/mcp.json (version 3)

Root cause

1. buildMcpTools (packages/runtime/src/mcp-tools.ts) builds each MCP tool with:

   parameters: jsonSchema(descriptor.inputSchema),

   In the bundled ai SDK v7, jsonSchema() returns a plain object wrapper:

   { _type: 'jsonSchema', jsonSchema: <original JSON Schema>, validate: fn }

   — NOT an instance of z.ZodType (verified at runtime: jsonSchema(...) instanceof z.ZodType === false, and it has no _def/parse, so toJSONSchema also fails).

2. These tools are handed to the desktop native capability provider as the desktop_mcp group (dist/main/runtime-host-boot.js, additionalGroups()).

3. The capability provider validates every tool schema:

   // dist/main/runtime-host-native-capabilities.js
   function requireZodSchema(tool) {
     if (!(tool.parameters instanceof z.ZodType)) {
       throw new Error(`Desktop native capability tool has an invalid schema: ${tool.name}`);
     }
     return tool.parameters;
   }

   Called from both toolInputSchema() (capability offer build) and invokeNativeTool().

4. With any MCP tool present, requireZodSchema throws → the native capability provider / capability composition fails → runtime-host cannot connect → Maka is effectively down (no crash dialog; app hangs with dead IPC).

Impact

• Configuring any MCP server (stdlib, filesystem, my custom one, etc.) bricks the desktop session until mcpServers is emptied.
• User-installed MCP servers are a headline feature — they currently cannot be used at all in 0.2.0.

Reproduction steps

1. In ~/Library/Application Support/Maka/workspaces/default/mcp.json (version 3), add any stdio server, e.g.:

   { "version": 3, "mcpServers": { "test": {
     "command": "node", "args": ["/path/to/server.mjs"], "protocol": "auto" } } }

2. Restart Maka.

3. Observe: execution-candidate-main.js fails to stay connected, IPC (skills/memory/settings) hangs; the log shows the capability throw for the MCP tool name.

Expected behavior

• MCP tools register cleanly and become callable (as the MCP protocol intends), without crashing the capability provider.

Suggested fix (pick one)

• A (recommended): In buildMcpTools, convert the MCP JSON Schema into a real zod schema instead of wrapping it with ai.jsonSchema() (e.g. a small recursive JSON-Schema→zod converter for object/array/string/number/boolean/enum/required/optional, falling back to z.unknown() — MCP servers validate their own args anyway). This makes tool.parameters instanceof z.ZodType true and keeps toJSONSchema() working.
• B: Relax requireZodSchema / toolInputSchema to accept the ai jsonSchema wrapper (or any object with a .jsonSchema field) and convert it there.

Verified workaround

• Keep mcpServers empty ({"version":3,"mcpServers":{}}) — the app runs fine without MCP servers.
• A local patch implementing fix A (a mcpSchemaToZod converter in mcp-tools.js) restores MCP servers fully: 5 tools from a custom MCP server registered and were callable without any crash.

[ser163]

Closed: 将改用 Bug 报告表单重新提交以自动附加 bug 标签（API 创建无法打标签）。