Idea: Provide an array of prompts to run in parallel

[nickpoorman]

Claude code seems to do things serially. And adding this as an mcp server to Claude Code and then telling it to act as a supervisor and deligate all tasks to this MCP works really well.

It might work even better if we can instruct the "supervisor" to collect tasks that can be worked on in parallel and supply them as a batch to this MCP server. So instead of a single prompt: ... it's something like an array of prompts, create a promise for each one and join the promises back with their results.

Imagine I have a list 1000 files and I tell Claude code to add the Apache license header at the top of each file (stupid example but you get the idea). Then the main Claude code loop could go and break it up into batches of 10 prompts and supply them to this MCP to run against claude code asynchronously.

So instead of:

claude-code-mcp:claude_code (MCP)(prompt: "Your work folder is /Users/nick/myproject\n\nAdd the Apache license folder to src/a.ts")

It would be something like:

claude-code-mcp:claude_code (MCP)([
  prompt: "Your work folder is /Users/nick/myproject\n\nAdd the Apache license to the top of src/a.ts", 
  prompt: "Your work folder is /Users/nick/myproject\n\nAdd the Apache license to the top of src/b.ts",
  prompt: "Your work folder is /Users/nick/myproject\n\nAdd the Apache license to the top of src/c.ts"
])

[dmikushin]

Thank you for highlighting perhaps the most promising direction for the development of this utility. I did some research and noticed that the wait=false mode added by @nicobailon is essentially equivalent to your technical solution. In this mode, the parent LLM can initiate asynchronous MCP requests without waiting for their completion. This option is present but is not active: wait=true is always used, meaning the parent LLM always waits for the MCP request to complete. Even wait=true is beneficial as it allows models mixing and helps the parent LLM maintain focus on the main task. However, for parallelism, we need wait=false. As I mentioned, it exists but performs unsatisfactorily. I tested a modification adding wait to the claude_code MCP tool description with Claude as the task distributor and noticed several serious issues:

1. Node warnings in MCP requests to Claude about exceeding some network requests. It seems there are many errors in request handling, possibly due to aggressive retries. I also suspect this activity quickly exhausted my daily Claude limit.
2. The parent LLM (also Claude in my case) cannot correctly assess the state of MCP workers and eventually decides they are stuck, attempting to terminate them forcefully.
3. The parent LLM forcefully terminates MCP workers without receiving any (from its perspective) results and continues to handle tasks itself. However, MCP workers were still running in the background. I found these processes in the task manager and terminated them manually.

[dmikushin]

Hi @nicobailon, kindly comment on this if you wish. I can't create issues in your fork anyways.