feat(mcp,desktop): bulk workspace operations#1088
Conversation
Convert create_workspace, delete_workspace to accept arrays (1-5 items) and add new update_workspace tool. Follows the bulk pattern established by task operations, with sequential processing and partial failure support.
📝 WalkthroughWalkthroughAdds bulk workspace operations across desktop and MCP: create, delete now accept 1–5 items; introduces a new update_workspace tool (renderer + MCP); adds BulkItemError and buildBulkResult utilities; wires updateWorkspace into ToolContext and MCP tool registry. Changes
Sequence DiagramsequenceDiagram
participant Agent as Agent/User
participant Renderer as Desktop Tool
participant Context as ToolContext
participant MCP as MCP Server / executeOnDevice
participant Aggregator as buildBulkResult
Agent->>Renderer: Invoke bulk tool (1-5 items)
Renderer->>Context: Read mutation functions (create/delete/update)
loop for each item
Renderer->>MCP: executeOnDevice / mutation (item)
alt Success
MCP-->>Renderer: item success
Renderer->>Renderer: push to items[]
else Failure
MCP-->>Renderer: item error
Renderer->>Renderer: push to errors[] (index, id, message)
end
end
Renderer->>Aggregator: buildBulkResult(items, errors, itemKey, total)
Aggregator-->>Agent: CommandResult (data summary + optional errors)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🧹 Preview Cleanup CompleteThe following preview resources have been cleaned up:
Thank you for your contribution! 🎉 |
The schema said name was optional but the handler errored if omitted. Since renaming is the only supported operation, make it required at the schema level so agents get a clear validation error upfront.
saddlepaddle
left a comment
saddlepaddle
left a comment
There was a problem hiding this comment.
PR Review: bulk workspace operations
Overall Assessment
Clean, well-structured PR. The code is consistent, well-typed, and follows existing patterns appropriately. LGTM.
What's Good
Shared bulk infrastructure — BulkItemError and buildBulkResult in types.ts eliminate duplication across all three handlers. The generic helper is well-typed and produces a consistent response shape (items + summary + optional errors). This is a meaningful improvement over duplicating the logic.
Consistent API surface — All three tools follow the same contract:
create_workspace:{ deviceId, workspaces: [...] }delete_workspace:{ deviceId, workspaceIds: [...] }update_workspace:{ deviceId, updates: [...] }- Response:
{ [key]: items[], summary: { total, succeeded, failed }, errors?: [] }
Partial failure semantics — Each item is processed independently with try/catch per iteration. One failure doesn't abort the batch. success: true when any item succeeds. This is the right behavior for workspace operations where items are independent.
Schema discipline — The follow-up commit (cb117a9) correctly tightened name to required in update_workspace after noticing the schema/handler mismatch. Good catch.
Clean MCP↔desktop boundary — The MCP layer stays thin (validate + executeOnDevice), and the desktop renderer handles the actual bulk loop. This separation is correct since workspace mutations require React Query context.
Minor Notes (non-blocking)
-
taskIdremoved fromcreate_workspace— The oldcreate_workspaceaccepted an optionaltaskIdparam. This PR silently drops it. ConfirmedtaskIdis not referenced in any workspace tool handler, and no callers in the codebase pass it tocreate_workspace, so this is safe. Worth noting for changelog purposes though. -
Error context fields on
BulkItemError— The[key: string]: unknownindex signature is pragmatic (allowsname,branchName,workspaceIdetc. as contextual fields per-tool). A discriminated union per tool would be more precise, but given these are serialized for MCP responses, the flexibility is fine here. -
5 vs 25 item limit — Workspace ops cap at 5 items while task ops allow 25. This makes sense given workspace creation involves git worktree operations (heavier), but the asymmetry could surprise callers. The
.describe()annotations document it clearly. -
Sequential processing — All three tools use
for...ofwithawaitinside the loop (sequential). For workspace operations this is correct — creating worktrees in parallel could cause git conflicts. Just noting the intentional choice.
Verification
bun run typecheck: 17/17 packages passbun run lint: 1506 files checked, no issues
1 participant
Summary
create_workspaceanddelete_workspaceMCP tools from single-item to bulk (1-5 items per call)update_workspacetool for bulk renaming workspacespackages/mcp) and desktop handler layer (apps/desktop) updated in lockstepDetails
API changes:
create_workspace:{ deviceId, workspaces: [{ name?, branchName?, baseBranch? }] }delete_workspace:{ deviceId, workspaceIds: ["uuid", ...] }update_workspace(new):{ deviceId, updates: [{ workspaceId, name? }] }Agent-friendly design:
summary: { total, succeeded, failed }field for easy partial-failure detectionBulkItemErrortype andbuildBulkResulthelper eliminate duplication across handlersTest plan
bun run typecheckpasses (17/17 packages)bun run lintpassesbun testpasses (1195 pass, 0 fail)Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.