Local MCP server — tree_patch tool always fails with type-mismatch errors, regardless of input

Hi Workflowy team,

I’m testing the new local MCP server (beta) on Workflowy Desktop, connected through Claude Desktop via the mcp-remote bridge (since the local HTTP endpoint isn’t accepted directly by Claude’s custom-connector UI, which requires HTTPS). Setup:

json

"workflowy-mcp": {
  "command": "npx",
  "args": ["-y", "mcp-remote", "<my Workflowy connection link>"]
}

Read operations work perfectly: tree_seek correctly returns my full tree, including nested filters and arrays in the request payload.

However, the tree_patch tool (used to write/mutate the tree) fails on every call, no matter what I send. Example call:

json

{
  "requests": [{"op": "insert", "parent_id": "0ef3279e9c9f", "text": "Poser congé le 11/09"}],
  "leases": [],
  "lease_ttl_seconds": 60
}

Response:

json

{
  "error": {
    "code": -32602,
    "message": "Invalid params for method 'tools/call'. See error.data for details.",
    "data": {
      "errors": [
        {"expected":"array","code":"invalid_type","path":["leases"],"message":"Invalid input: expected array, received string"},
        {"expected":"number","code":"invalid_type","path":["lease_ttl_seconds"],"message":"Invalid input: expected number, received string"},
        {"expected":"array","code":"invalid_type","path":["requests"],"message":"Invalid input: expected array, received string"}
      ]
    }
  }
}

Notably, lease_ttl_seconds is a plain number (60) in my request, yet the server reports it as received as type “string.” The same happens for requests and leases regardless of whether I send arrays of objects, arrays of strings, or bare objects — the error is always “expected array/number, received string.” This strongly suggests the arguments are being serialized (e.g., JSON-stringified) somewhere in the pipeline before reaching the tree_patch schema validator — while the equivalent nested array/object parameters work fine for tree_seek.

Could you take a look? Happy to share more logs or reproduce with more detail if useful.

Thanks for building this — read access alone is already really valuable, looking forward to write support working too.

1 Like

I haven’t been able to reproduce this issue.

Could you first:

  1. Update Workflowy Desktop to the latest version.
  2. Update your Claude MCP configuration to the following, then restart Claude Desktop:
  "workflowy-mcp": {
    "command": "npx",
      "args": ["-y", "mcp-remote@latest", "<your Workflowy connection link>"]
  }

Using mcp-remote@latest ensures you’re running the latest bridge version.

After restarting, please try again in a fresh Claude Desktop chat. Does the same type-mismatch error still occur?