# Throng MCP [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/agent-runbooks/throng-mcp  
**GitHub Stars:** 2  
**npm Downloads (last month):** 1471  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/throng-mcp

## Description
MCP server that delegates work to another agent harness or model over ACP

## Tools
Capabilities this server exposes over MCP:

- **cancel_thronglet** — Cancels the session's running turn (session/cancel) and drops its queued messages; a pending wait_thronglet returns the cancelled error. The session is idle afterwards and accepts a new send_message. No-op on an idle session.
- **list_harnesses** — Lists valid agent values for run_thronglet: installed harnesses with their models and effort levels, installed or configured ones that cannot run with the reason, and the server limits. Built-in harnesses that are not installed are not listed.
- **list_thronglets** — Lists thronglet sessions on this machine: description, agent, cwd, state (running | queued | idle | failed), queue length, accepts_messages (false: send_message to it fails), timestamps and the last error. Live state is this server's; a session run by another throng instance shows what its record says.
- **run_thronglet** — Runs an agent of an installed harness (see list_harnesses) on a task in cwd and returns its final message as JSON {session_id, text, stop_reason, usage, duration_s, warnings?}; with schema, structured replaces text. description names the thronglet for listings. With background: true the call returns {session_id, state, queued} as soon as the turn runs; collect the result with wait_thronglet.
- **send_message** — Sends the next message into an earlier session (session_id from run_thronglet) and returns the same JSON as run_thronglet. A message to a session whose turn is still running waits for that turn to end: turns on one session never overlap. With background: true the call returns {session_id, state, queued} as soon as the turn runs; collect the result with wait_thronglet. steer: true interrupts the running turn and delivers this message next; queued messages follow it. A session its harness cannot continue (resume or load) takes no further message, steer included: list_thronglets shows it as accepts_messages: false.
- **wait_thronglet** — Waits until a session has no running or queued turn and returns the last turn's result: the same JSON as run_thronglet, or its error. With timeout_s elapsed returns {session_id, state, queued} instead. Idempotent: the result is stored with the session.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "throng-mcp": {
    "command": "npx",
    "args": ["-y","throng-mcp"]
  }
}
```

## Documentation

## What Throng MCP does

Throng MCP routes work from one MCP client to another agent harness or model. Supported built-in harnesses include Claude Code, Codex, OpenCode, Gemini CLI, Cursor CLI, and GitHub Copilot CLI. Other ACP-compatible agents can be added as custom harnesses by describing their command and approval behavior.

The main workflow is delegation. A calling agent can ask one harness to inspect a repository, ask another to make changes, and then return to the first session for a follow-up review. This supports workflows such as independent code review, implementation followed by verification, and staged second opinions.

Results can be requested against a JSON Schema, allowing the caller to receive structured data such as findings, verdicts, plans, file locations, or reproduction steps instead of parsing free-form prose.

## How it works

The server communicates with MCP clients over stdio and starts nested agents through ACP. Claude Code and Codex use separate ACP adapters; OpenCode, Gemini CLI, Cursor CLI, and Copilot CLI expose ACP interfaces directly. Each nested session remains available for later messages, so follow-up requests retain the session's prior context.

A call can run synchronously or use background execution. Background work returns immediately, and a later wait operation collects the result. This makes it possible to run multiple agent tasks while continuing work in the primary session.

The nested agent operates in the directory supplied by the caller and uses the permissions of the account running it. A harness must be installed and authenticated separately before it can accept delegated work.

## Setup and configuration

Install the server with `npx -y throng-mcp`, which downloads and caches the package on first use, or install it globally with `npm i -g throng-mcp` and run `throng-mcp`. Node.js `^22.13` or `>=24` is required.

Register the command as a stdio server in the MCP client. Claude Code can use `claude mcp add --scope user throng -- npx -y throng-mcp`; Codex uses `codex mcp add throng -- npx -y throng-mcp`. Other MCP clients should register the same command as a local stdio server.

Install and authenticate each harness separately. Claude Code and Codex require their ACP adapter packages. OpenCode, Gemini CLI, Cursor CLI, and Copilot CLI provide ACP themselves. Gemini CLI requires a Gemini API key or Vertex configuration, while Cursor CLI and Copilot CLI require their respective login commands.

Custom harnesses can be configured with their executable command and the options controlling approval behavior. Throng does not install or infer settings for custom harnesses.

## Tools and capabilities

- `list_harnesses` checks installed adapters and reports available harnesses, models, effort levels, and configured harnesses that are unavailable.
- `run_thronglet` starts a delegated agent session with an agent selection, prompt, repository path, optional background mode, and optional JSON Schema.
- `send_message` sends additional work to an existing nested session while preserving its context.
- `wait_thronglet` retrieves the result of a background run.
- Structured responses can be constrained to a caller-provided JSON Schema.
- Multiple delegated sessions can run concurrently.

## Limitations and notes

The server does not include the agent CLIs or ACP adapters. Those components, along with their authentication, must be installed and configured independently. A harness that is not installed will not appear as available, and failed authentication can make an otherwise configured harness unavailable.

Built-in harness behavior has provider-specific limits documented by the project for Gemini CLI, Cursor CLI, and GitHub Copilot CLI. Copilot CLI authentication through only the GitHub CLI can prevent model selection and cause runs to fail; its own `copilot login` flow is required for that use case.

The optional `skills/throng` package teaches a calling agent when and how to use the server, but it is not required for the MCP server itself. New agent sessions may be needed after installing that skill.

_Full upstream README: https://allmcps.com/mcp/throng-mcp/readme_