# Pitroom [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/ATASTECH/pitroom  
**GitHub Stars:** 24  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/pitroom

## Description
Hands bounded coding work to cheaper worker agents: verified answers, exact diffs, cost receipts.

## Claude Desktop Quick Installation
Remote MCP endpoint (confidence: high). Install path detected from listing signals. Add as a URL/SSE server in your client:

```json
"mcpServers": {
  "pitroom": {
    "url": "http://127.0.0.1:7117/mcp"
  }
}
```

## Documentation

## What Pitroom does

The Pitroom MCP server hands bounded repository tasks to worker CLIs so a primary coding agent can delegate routine investigation and implementation without giving up final control. Workers can read code, make scoped fixes, run tests, and review results. The returned work includes an answer, cited locations, any detected changes, and a receipt describing worker token usage and estimated savings.

Pitroom is designed for tasks where the worker can operate within explicit permissions. It does not commit, push, reset, stash, rebase, publish, use `sudo`, or perform bulk deletion. A worker cannot expand the permissions assigned to its run. These controls reduce risk but are not described as a security boundary.

## How it works

A run uses the default model configured by the selected worker CLI; Pitroom does not hardcode a model. Workers may be started individually or as a crew, with up to 20 concurrent workers by default and a maximum of 30. A fallback chain can move to another configured worker after errors such as rate limits, quota failures, or a missing model.

For edits, isolate mode gives a worker a private copy of the current repository state, including uncommitted and untracked files. The result is returned as a patch that can be applied or discarded. Pitroom snapshots the working tree with a temporary Git index to distinguish worker edits from existing changes, without changing the user’s index, branches, or stash.

Citations such as `path:line` are checked against files on disk. The system also resolves citations that omit a directory when possible and avoids treating symbols such as `Schema.parse:432` as file references.

## Setup and configuration

Pitroom is distributed as an npm package and provides a `pitroom` command-line interface. The supplied material identifies quick-start usage through commands such as `pitroom run`, `pitroom crew`, and `pitroom models`, but does not provide a complete installation command or required environment-variable list.

Worker selection and model availability come from the worker CLIs. The `models` command reports available workers, supported effort levels, configured costs, and usage. Run records are stored under `~/.local/state/pitroom`; the project does not create a `.pitroom/` directory, modify `.gitignore`, or create branches.

## Tools and capabilities

The Pitroom MCP server’s documented CLI capabilities include:

- `run` for a single bounded task.
- `crew` for starting multiple workers.
- `watch --json` for streaming changes as one JSON line per update.
- `wait -g` for collecting a group’s answers.
- `apply` for landing an isolated patch, with deletion requiring `--allow-delete`.
- `discard` for abandoning an isolated result.
- `revert <id>` for undoing a worker’s recorded changes.
- `dash` for a local run dashboard with task, steps, results, diffs, history, and statistics.
- `history` for searching previous runs.
- `savings --card card.svg` for generating a shareable receipt card.

Workers can be assigned read-only, isolated-copy, in-place-edit, or web permissions. Web access is not enabled unless requested. `pitroom watch --json` and grouped commands support workflows where the primary agent follows several workers while continuing its own work.

## Limitations and notes

Pitroom depends on the worker CLIs and their configured models. The README names OpenCode, Codex CLI, Claude Code, Gemini CLI, Qwen Code, and Kilo Code as worker options, but availability, pricing, free tiers, quotas, and effort levels depend on those tools and their configuration. Parallel writers are refused, while read and review work can run concurrently.

The documented safeguards are intended to constrain normal worker behavior, not to replace a security boundary. Isolated patches can be applied only after checks, and deletion is refused unless explicitly allowed. The provided material does not document a dedicated MCP transport, required environment variables, or client-specific installation steps.

_Full upstream README: https://allmcps.com/mcp/pitroom/readme_