What happened
An MCP server configured in the TUI (persisted to the workspace's shared mcp.json) fails to load in the Desktop app. On npm run dev, the Runtime Host logs repeatedly:
[runtime-host] MCP startup failed: Error: Desktop native capability tool has an invalid schema: mcp__<server>__<tool>
[runtime-host] MCP capability refresh failed: Error: Desktop native capability tool has an invalid schema: mcp__<server>__<tool>
As a result, no MCP tool from any configured server is offered to sessions on Desktop. It is non-fatal (both call sites are .catch(console.error)), so the app keeps running — but MCP is effectively unusable in the Desktop app. The same MCP server works fine in the TUI.
Root cause. buildMcpTools() (packages/runtime/src/mcp-tools.ts:117) sets every MCP tool's parameters to jsonSchema(descriptor.inputSchema) — an AI SDK Schema object, not a Zod type. The Desktop side re-offers these tools to the Runtime Host over the client-capability protocol, going through capabilityOffer → toolInputSchema → requireZodSchema (apps/desktop/src/main/runtime-host-native-capabilities.ts:450,467), which insists tool.parameters instanceof z.ZodType and throws on the first MCP tool. The same requireZodSchema guard is also used for call-time argument validation (invokeNativeTool, runtime-host-native-capabilities.ts:340).
The TUI works because buildMcpTools() output goes straight to the model layer, where jsonSchema() params are the expected format. Desktop additionally crosses the desktop→Runtime-Host capability-offer boundary, and only that boundary enforces Zod. The protocol's receiving side (packages/runtime-host/src/server/client-capability-coordinator.ts:600) rebuilds the same tools via buildMcpTools and accepts jsonSchema() fine — so the two halves of the protocol disagree on the allowed parameters shape.
How to reproduce
- Configure any MCP server (e.g. a filesystem server exposing a
read_file tool) — via the TUI, or by adding it to the workspace's mcp.json.
- Open the same workspace in the Desktop app and run
npm run dev.
- Observe the Runtime Host log:
MCP startup failed: ... Desktop native capability tool has an invalid schema: mcp__<server>__<tool> (and the same on every MCP refresh).
- The MCP server's tools are never available to sessions on Desktop.
This reproduces for any connected MCP server with at least one tool, because all MCP tools carry jsonSchema() parameters rather than Zod schemas.
Environment
- Maka commit:
eacfb46aa
- OS and version: macOS 15.7.3 (Darwin 24.6.0)
- Surface: Desktop
- Node.js version (running from source): v24.14.0
Logs, screenshots, or additional context
[runtime-host] MCP capability refresh failed: Error: Desktop native capability tool has an invalid schema: mcp__<server>__<tool>
at requireZodSchema (.../apps/desktop/dist/main/main.js)
at toolInputSchema (.../apps/desktop/dist/main/main.js)
at capabilityOffer (...)
at createDesktopNativeCapabilityProvider (...)
at createNativeProvider (...)
[runtime-host] MCP startup failed: Error: Desktop native capability tool has an invalid schema: mcp__<server>__<tool>
...
Both log lines originate from the same publisher (mcpCapabilityPublisher): MCP startup failed at Runtime Host boot, and MCP capability refresh failed on every MCP server change.
What happened
An MCP server configured in the TUI (persisted to the workspace's shared
mcp.json) fails to load in the Desktop app. Onnpm run dev, the Runtime Host logs repeatedly:As a result, no MCP tool from any configured server is offered to sessions on Desktop. It is non-fatal (both call sites are
.catch(console.error)), so the app keeps running — but MCP is effectively unusable in the Desktop app. The same MCP server works fine in the TUI.Root cause.
buildMcpTools()(packages/runtime/src/mcp-tools.ts:117) sets every MCP tool'sparameterstojsonSchema(descriptor.inputSchema)— an AI SDKSchemaobject, not a Zod type. The Desktop side re-offers these tools to the Runtime Host over the client-capability protocol, going throughcapabilityOffer → toolInputSchema → requireZodSchema(apps/desktop/src/main/runtime-host-native-capabilities.ts:450,467), which insiststool.parameters instanceof z.ZodTypeand throws on the first MCP tool. The samerequireZodSchemaguard is also used for call-time argument validation (invokeNativeTool,runtime-host-native-capabilities.ts:340).The TUI works because
buildMcpTools()output goes straight to the model layer, wherejsonSchema()params are the expected format. Desktop additionally crosses the desktop→Runtime-Host capability-offer boundary, and only that boundary enforces Zod. The protocol's receiving side (packages/runtime-host/src/server/client-capability-coordinator.ts:600) rebuilds the same tools viabuildMcpToolsand acceptsjsonSchema()fine — so the two halves of the protocol disagree on the allowedparametersshape.How to reproduce
read_filetool) — via the TUI, or by adding it to the workspace'smcp.json.npm run dev.MCP startup failed: ... Desktop native capability tool has an invalid schema: mcp__<server>__<tool>(and the same on every MCP refresh).This reproduces for any connected MCP server with at least one tool, because all MCP tools carry
jsonSchema()parameters rather than Zod schemas.Environment
eacfb46aaLogs, screenshots, or additional context
Both log lines originate from the same publisher (
mcpCapabilityPublisher):MCP startup failedat Runtime Host boot, andMCP capability refresh failedon every MCP server change.