Skip to main content
Glama
CaptainCrouton89

Claude Parallel Tasks MCP Server

Claude Parallel Tasks MCP Server

An MCP (Model Context Protocol) server that enables running multiple Claude prompts in parallel, with optional file contexts and output redirection.

Features

  • Run multiple Claude prompts simultaneously in parallel

  • Provide file contexts to Claude prompts

  • Redirect output to individual files for each task

  • Built with TypeScript and the MCP SDK

Related MCP server: par5-mcp

Prerequisites

  • Node.js and pnpm

  • Claude CLI tool installed and configured

  • Anthropic API key

Setup

  1. Clone the repository:

git clone https://github.com/CaptainCrouton89/claude-code-mcp.git
cd claude-code-mcp
  1. Install dependencies:

pnpm install
  1. Set up your environment variables:

cp .env.example .env.local
  1. Edit .env.local and add your Anthropic API key:

ANTHROPIC_API_KEY=your_anthropic_api_key_here
  1. Build the project:

pnpm run build

Usage

Running the Server

pnpm start

Configuring with Claude Desktop

Add the following to your claude_desktop_config.json:

{
  "mcpServers": {
    "claude-parallel": {
      "command": "node",
      "args": ["/path/to/claude-code-mcp/dist/index.js"],
      "env": {
        "ANTHROPIC_API_KEY": "your_anthropic_api_key_here"
      }
    }
  }
}

Available Tools

run_parallel_claude_tasks

Runs multiple Claude prompts in parallel with optional file contexts.

Parameters:

  • queries: Array of query objects, each containing:

    • queryText: The text prompt to send to Claude

    • contextFilePaths (optional): Array of file paths to provide as context

Example:

{
  "queries": [
    {
      "queryText": "Explain this code",
      "contextFilePaths": ["src/index.ts"]
    },
    {
      "queryText": "Write a summary of this project",
      "contextFilePaths": ["README.md", "package.json"]
    }
  ]
}

Development

# Install dependencies
pnpm install

# Build the project
pnpm run build

# Run in development mode
pnpm run dev

Security

  • API keys are stored in environment variables, not in code

  • The .env.local file is gitignored to prevent accidental commits

  • Use the provided .env.example as a template

License

MIT

Available Tools

1 tool
run_parallel_claude_tasksB

Runs multiple Claude prompts in parallel, optionally with file contexts, redirecting output to files.

ParametersJSON Schema
NameRequiredDescriptionDefault
queriesYesA list of query objects to run with Claude in parallel

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions parallel execution and output redirection to files, which are useful behavioral traits. However, it omits critical details such as error handling, performance implications (e.g., rate limits or concurrency limits), authentication requirements, or what happens if file contexts are invalid. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core functionality ('Runs multiple Claude prompts in parallel') and appends key features ('optionally with file contexts, redirecting output to files'). There is no wasted verbiage, and every phrase adds meaningful information, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (parallel execution with file handling), lack of annotations, and no output schema, the description is moderately complete. It covers the basic operation and key features but misses details like error behavior, output format, or system constraints. Without annotations or output schema, more context would be helpful, but the description provides a functional overview.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single parameter ('queries') and its nested properties ('queryText' and 'contextFilePaths'). The description adds some value by implying that 'queries' are run in parallel and that 'contextFilePaths' are optional file contexts, but it doesn't provide additional semantic details beyond what the schema specifies. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Runs multiple Claude prompts in parallel, optionally with file contexts, redirecting output to files.' It specifies the verb ('Runs'), resource ('multiple Claude prompts'), and key features (parallel execution, file contexts, output redirection). Since there are no sibling tools, no differentiation is needed, making this a clear but not maximally specific description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It mentions the tool's capabilities but offers no context about prerequisites, typical use cases, or scenarios where it might be preferred over sequential execution or other methods. Without sibling tools, this is less critical, but the description still lacks usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

TDQS

B3.2/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap with other tools, making disambiguation perfect. The tool's purpose is clearly defined and distinct by default.

Naming Consistency5/5

The single tool name follows a clear verb_noun pattern (run_parallel_claude_tasks), and with no other tools to compare, consistency is inherently perfect. There are no deviations or mixed conventions.

Tool Count2/5

A single tool is too few for a server named 'Claude Parallel Tasks MCP Server', which suggests a broader scope for managing parallel tasks. This minimal set feels thin and underdeveloped for the implied functionality.

Completeness2/5

The server lacks essential operations for a parallel tasks domain, such as listing, monitoring, canceling, or retrieving results of tasks. With only a run tool, the surface is severely incomplete and will likely cause agent failures in managing task lifecycles.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CaptainCrouton89/claude-code-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server