crew-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CREW_SCOUT | No | Quick override for the scout role worker chain (e.g., 'local,chatgpt'). | |
| CREW_NUM_CTX | No | Quick override for the number of context tokens (e.g., 16384). | |
| CREW_REVIEWER | No | Quick override for the reviewer role worker chain (e.g., 'chatgpt'). | |
| CREW_WORKSPACE | No | Set the workspace directory for the server to use instead of the launch directory. | |
| CREW_OLLAMA_URL | No | Quick override for the Ollama server URL (e.g., http://localhost:11434). | |
| CREW_OLLAMA_MODEL | No | Quick override for the Ollama model to use (e.g., a model name). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| crew_statusA | Show crew configuration, the workspace it will read, and which workers (local GPU, ChatGPT, API) are available. Run this first if another crew tool errors. |
| crew_reconA | Send a scout (local GPU first, ChatGPT as fallback) to map the code relevant to a question: files, functions, coverage of each stage, and evidence-backed risks. Use it before reading lots of files yourself, to save your context. Results are leads to confirm, not proof. |
| crew_review_diffA | Have a scout review the current working-tree changes (staged, unstaged and new files) for bugs, security, concurrency and data-integrity problems. Findings are split into evidence-checked (the quoted code really exists) and unverified. Run it after making changes and before saying you're done. |
| crew_second_opinionA | Ask an independent reviewer (ChatGPT by default) to critique a plan, a design, or the current diff. Use it for risky work: payments, auth, migrations, concurrency. Expect disagreement; weigh it, don't just accept it. |
| crew_check_citationsA | Deterministically check file:line references in a piece of text against the repository: the file exists, the lines exist, and a backticked identifier on the same line really appears near those lines. No model involved. Use it on your own analysis before presenting it. |
| crew_statsA | Show what the crew did: per worker, calls, time, files and characters read, tokens generated, and findings quote-checked vs unverified. ChatGPT calls show calls and time only. Includes a clearly labeled ESTIMATE of context kept out of Claude. Read from a local metadata-only log (no prompts or code). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool has a distinct role: recon maps code, review_diff audits working-tree changes, second_opinion critiques plans/diffs, check_citations verifies file:line refs deterministically, stats reports telemetry, status reports config. The only real overlap is crew_review_diff vs crew_second_opinion, both of which can consume the current diff, but the descriptions clearly separate a local scout bug review from an independent model reviewer.
All six names share the crew_ prefix and snake_case, giving a predictable namespace. Minor deviation: most are verb_noun (review_diff, check_citations, second_opinion) while recon, stats and status are bare nouns, but the pattern remains readable and unambiguous.
Six tools is well within the well-scoped range and each earns its place: three work tools (recon, review, second opinion), one deterministic checker, and two introspection tools (status, stats). No tool looks like filler or a near-duplicate.
The surface covers the full delegation lifecycle for its stated purpose: check availability (status), gather context (recon), review (review_diff, second_opinion), verify claims (check_citations), and audit usage (stats). Minor gaps exist around configuring workers or cancelling long-running jobs, but agents can work around these with a status call.