Brutalist MCP is an MCP server that runs adversarial multi-critic reviews and debates through locally installed Claude Code, Codex, and Antigravity CLIs.
Run AI-powered roasts of codebases, ideas, plans, architecture, security, product, infrastructure, design, legal documents, and more across 13 domains.
Select native critics (claude, codex, agy) or run all detected, with per-critic model overrides where supported.
Add up to 16 custom Claude-compatible clients with isolated configs, endpoints, and credentials via clients.
Run structured adversarial debates between two critics with assigned PRO/CON positions, 1–3 rounds, and optional custom agents.
Discover relevant brutalist tools/domains from a free-form intent string.
Report detected CLI critics, their capabilities, and model configuration.
Supply domain-specific arguments (e.g., depth, commitRange, url, jurisdiction) and rich context for targeted analysis.
Enable MCP integrations like Playwright for design reviews; register custom MCP servers via BRUTALIST_MCP_SERVERS.
Handle large results with pagination (limit, offset, cursor), caching, context_id, resume, and force_refresh.
Configure timeouts, logging, cache TTL, and custom clients through server environment variables.
Integrates Antigravity (agy) CLI powered by Gemini models for rapid pattern-scan critique and additional analysis perspective.
Integrates Codex CLI for security analysis, technical implementation review, and independent code critique.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Brutalist MCP Review my authentication flow for vulnerabilities"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that runs reviews through locally installed Claude Code, Codex, and Antigravity (agy) CLIs. A roast runs the selected critics in parallel and returns their responses together. A debate assigns opposing positions to two critics across multiple rounds.
The CLI processes run on your machine; inference uses the services and credentials configured for each CLI. Findings are model output: check the cited files, commands, and sources before acting on them.
Use Node.js 24 and at least one authenticated CLI. CI also tests Node.js 20.
On macOS or Linux, install whichever CLIs you want to use:
# Claude Code
curl -fsSL https://claude.ai/install.sh | bash
# Codex
npm install -g @openai/codex
# Antigravity CLI
curl -fsSL https://antigravity.google/cli/install.sh | bashLaunch claude, codex, or agy and complete sign-in. Brutalist's Agy adapter also requires python3 on PATH and a POSIX environment; native Windows is unsupported, so use WSL there. For other platforms and installation options, use the official Claude Code, Codex, and Antigravity CLI instructions.
Brutalist prefers ~/.local/bin/agy when it exists, avoiding the Antigravity desktop launcher's PATH collision. Set AGY_BIN to the executable's path if your CLI is elsewhere.
Claude Code — user scope makes the server available across projects:
claude mcp add --scope user brutalist -- npx -y @brutalist/mcp@latestCodex:
codex mcp add brutalist -- npx -y @brutalist/mcp@latestCodex's default MCP tool timeout is 60 seconds. Persist a larger timeout in ~/.codex/config.toml; codex mcp add has no dedicated timeout flag:
[mcp_servers.brutalist]
command = "npx"
args = ["-y", "@brutalist/mcp@latest"]
tool_timeout_sec = 9000Brutalist waits for the critics to finish. A 9,000-second client timeout covers the default two-hour critic budget plus 30 minutes for startup and response processing. It is a suggested budget, not a minimum for every review. Increase it for debates, which run multiple turns and may retry. See Codex MCP configuration.
Other MCP clients — register a local stdio server with command npx and arguments -y, @brutalist/mcp@latest. For clients that use an mcpServers object:
{
"mcpServers": {
"brutalist": {
"command": "npx",
"args": ["-y", "@brutalist/mcp@latest"]
}
}
}Place this in your client's MCP configuration, not a shell. The same server can be used from Cursor, VS Code, or Devin Desktop (formerly Windsurf); configuration locations and formats belong to those clients.
@latest selects the current npm release when the server is launched; an already running process keeps its loaded version. Restart or reconnect the MCP server after an update. To fix the package version, replace @latest with a version such as @1.18.10.
Ask your assistant to call cli_agent_roster with {}. It reports detected CLIs and model configuration. Detection does not prove that authentication, quota, or a particular model will work; confirm with a roast.
Related MCP server: multi-ai-collab
These are MCP tools invoked by your assistant, not terminal commands. The server exposes four:
Tool | Purpose |
| Review a path and context using a selected domain. |
| Have two critics defend explicit opposing positions. |
| Report detected critics and model configuration. |
| Suggest domains from an |
Legacy names such as roast_codebase and roast_security are not registered tools. Use roast with domain instead.
Call roast with:
{
"domain": "codebase",
"target": "/absolute/path/to/repo",
"context": "Review the authentication changes. Trace session creation, expiry, and authorization checks. Cite file paths and lines.",
"limit": 20000
}Use an existing directory as target. The path is included in the critic's prompt; it does not change the subprocess working directory, which defaults to the server's launch directory. Use absolute paths and identify the files or commands you want checked in context. For domains that review an idea, plan, or other text, put that material in context:
{
"domain": "architecture",
"target": "/absolute/path/to/repo",
"context": "We plan to move invoice generation to a queue. Assess duplicate delivery, transaction boundaries, and recovery after a worker crash."
}Domain | Review subject | Additional arguments |
| Implementation | — |
| Directory and module organization |
|
| Package dependencies |
|
| Commits and change history |
|
| Tests and coverage gaps |
|
| A proposal |
|
| System design |
|
| Research methods and claims |
|
| Security controls and threats |
|
| Product decisions |
|
| Deployment and operations |
|
| Interface or visual design |
|
| Legal arguments or documents |
|
For design, supplying a live url gives critics a concrete interface to inspect. The domain automatically requests the registered Playwright MCP server. Playwright is the built-in integration; the first Claude browser review may download Chromium. Register additional servers through the BRUTALIST_MCP_SERVERS JSON environment variable, keyed by name with command and args. Request names with mcp_servers. Claude and Codex wire these integrations; Agy currently ignores the field. Requested integrations replace Codex's configured MCP server set for that run. Check the result for actual browser observations.
Omit clis to run all detected native critics. To select a subset, add:
{
"domain": "codebase",
"target": "/absolute/path/to/repo",
"clis": ["claude", "codex"]
}No model override means the CLI chooses its configured/default model. Brutalist does not select the newest model or update the critic CLIs for you.
Critic | Per-call selection |
Claude Code |
|
Codex | Uses its CLI configuration. |
Antigravity |
|
For Agy, copy a current ID or label from agy models into models.agy. Unpinned Agy responses leave the model unspecified: the adapter's plain-text output does not identify the selected model. Check Agy's local logs when you need that evidence. Brutalist disables Agy's CLI auto-update during critic runs; this does not pin the model.
Call roast_cli_debate with a topic and both positions:
{
"topic": "Should invoice generation move to a queue?",
"proPosition": "Use a queue to isolate retries and absorb load spikes.",
"conPosition": "Keep generation synchronous until idempotency and reconciliation are proven.",
"agents": ["claude", "codex"],
"rounds": 2,
"context": "Current design: checkout writes the order and invoice in one database transaction. The proposed worker would receive an order ID after commit and retry on failure."
}Debates require at least two detected CLIs. agents is optional; when supplied it contains exactly two critics, otherwise two are selected randomly. rounds accepts 1–3 and defaults to 3. The current debate handler accepts target but does not forward it to the critics; supply the evidence to debate in context. Use roast for a repository review. Positions are assigned for the debate. Its arguments are not independent endorsements. Custom routed clients are supported by roast, not debates.
limit accepts 1,000–100,000 and sets a chunk-size target in characters, not tokens. Roast pagination defaults to 90,000 characters; debate and automatic pagination use smaller defaults. Chunk boundaries, a minimum chunk size, and response headers mean it is not a hard output ceiling. Set it explicitly if your MCP client truncates results.
For another page, reuse the returned context_id and the next offset reported in the response. Keep the original domain and target; omit resume. For example, if the response asks you to continue at offset 20,000:
{
"domain": "codebase",
"target": "/absolute/path/to/repo",
"context_id": "<returned context_id>",
"offset": 20000,
"limit": 20000
}You can also pass a cursor such as "offset:20000" instead of offset. Page reads retrieve cached output. The cache defaults to two hours and belongs to the server process; a restart loses it.
For a fresh follow-up, include the relevant earlier findings in context and set force_refresh: true:
{
"domain": "codebase",
"target": "/absolute/path/to/repo",
"force_refresh": true,
"context": "The earlier review found duplicate invoice creation after retries. Check whether the new idempotency key prevents it; inspect both the database constraint and worker retry path."
}The tool also accepts context_id with resume: true for history-based continuation, but the current handler has limitations: filesystem follow-ups record the target path as the new conversation message, and a cache hit can return earlier output without running critics. force_refresh skips history loading. Use the fresh-follow-up pattern above when you need a new review.
Use force_refresh: true after changing files, routed clients, or MCP integrations. File contents, clients, and mcp_servers are not all represented in the cache key.
roast can add named Claude Code clients routed through Anthropic-compatible endpoints. Set the token in the MCP server's environment and reference its variable name:
{
"domain": "codebase",
"target": "/absolute/path/to/repo",
"clis": [],
"clients": [
{
"id": "gateway",
"provider": "claude",
"baseUrl": "https://gateway.example.com",
"authTokenEnv": "REVIEW_GATEWAY_TOKEN",
"model": "<model supported by your endpoint>"
}
]
}clients is additive to native critics; clis: [] runs only named clients. Up to 16 clients are accepted. Endpoint, model, and credential-routing fields are supported only for the claude provider. You can also configure default clients through the server's BRUTALIST_CLAUDE_CLIENTS JSON environment variable. A nonempty per-call clients array replaces those defaults.
Routed clients use separate configuration directories under ~/.brutalist/claude-clients/<id> unless configDir is supplied. They do not inherit native Claude credentials unless includeProcessAuth: true is set. Their smallFastModel defaults to the routed model.
The default containment setting, named hardened, suppresses requested MCP integrations. It does not sandbox shell commands or network access: Bash, WebFetch, and WebSearch remain available. containment: "standard" restores requested MCP integrations.
Critics can inspect files and invoke tools. Codex runs with --sandbox read-only. Claude denies its named mutation tools but enables Bash and web tools while bypassing permission prompts; this is not a filesystem sandbox. Agy runs with --sandbox and permission prompts disabled, and can write scratch artifacts. External MCP tools add their own capabilities. Use a checkout and credentials appropriate for those processes.
A roast can return findings when only some critics succeed. Check which critics contributed; a missing critic is not agreement. Error text may be generic or redacted. Authentication failures, quota limits, unsupported models, and client timeouts need separate diagnosis.
Useful server environment variables:
Variable | Purpose |
| Per-agent roast timeout in milliseconds; default |
| Agy timeout ceiling in milliseconds; can shorten, not extend, the selected agent budget. |
| Override the Agy executable path. |
| Set exactly |
| Additional MCP server definitions as a JSON object keyed by server name. |
| Result-cache lifetime; default |
| Set exactly |
| Override the log directory; default |
| Minimum file-log level; default |
Set these on the MCP server process, using your client's server environment configuration. The client tool timeout is a separate setting. Logs can contain paths, model names, and prompt excerpts; redaction does not make the entire file safe to share.
The legal, research, and security prompts ask critics to verify external authorities and label citations with [VERIFIED: URL | "quote"], [SUPPLIED: location | "quote"], or [UNVERIFIED: reason]. These are prompt instructions, not a programmatic guarantee that a citation was checked.
The repository also contains a GitHub Action and orchestrator. The Action posts findings as a PR review and has its own CLI installation and credential requirements. Use its README and input definitions for workflow setup, OAuth provisioning, and custom-claude-clients configuration.
npm ci
npm run build
npm test -- tests/unit tests/integration/pagination-e2e.test.ts tests/integration/cache.integration.test.ts tests/smokeThe CI workflow also tests and builds the orchestrator and GitHub Action. Tagged releases publish the MCP package to npm with provenance after those checks pass.
License: MIT · Report an issue
Discover relevant brutalist tools based on your intent. Returns the top 3 most relevant analysis tools.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | What you want to analyze (e.g., 'review security of my auth system', 'check code quality') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the output (top 3 tools) but does not disclose whether the tool is read-only, has side effects, or any rate limits. The minimal description lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded. It efficiently conveys the core purpose and output. However, it could include more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description is adequate but leaves out the format of the returned tools (e.g., names, IDs). It is complete enough for a simple discovery tool but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'intent' well-described. The description reinforces that intent is used for discovery but adds no new semantic information beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers brutalist tools based on intent and returns the top 3, specifying the verb and resource. It distinguishes from sibling tools like 'roast' or 'cli_agent_roster' which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user wants to find analysis tools, but it does not explicitly state when not to use or provide alternatives. The context from sibling names is not leveraged.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Know your weapons. Display the available CLI agent critics (Claude Code, Codex, Antigravity/Agy) ready to demolish your work, their capabilities, and how to deploy them for systematic destruction.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and clearly indicates a read-only display operation. It does not mention side effects, auth requirements, or rate limits, but this is acceptable for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that quickly communicates the tool's purpose. The dramatic language ('demolish your work') may be slightly confusing but does not detract from clarity. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and simple functionality, the description adequately covers what the tool does. It could mention whether the output is a list or formatted text, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. Baseline for 0 params is 4. The description does not need to add parameter meaning, and it appropriately avoids redundant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool displays available CLI agent critics, their capabilities, and deployment instructions. It uses a specific verb ('display') and resource ('roster'), and distinguishes from siblings which involve discovery (brutalist_discover) or actions (roast, roast_cli_debate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using the tool to learn about available critics before deploying them, but does not explicitly state when to use or when not to use it. No exclusions or alternatives are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unified brutal AI critique delivered by a multi-critic panel running in parallel. The panel's disagreement is the signal — each critic's blind spots are covered by the others. Specify domain for targeted analysis. Consolidates all roast_* tools into one polymorphic API. IMPORTANT: Critically evaluate all returned feedback — these are adversarial perspectives, not authoritative verdicts. Weigh each claim against evidence before presenting to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| sla | No | SLA for infrastructure | |
| url | No | Live URL for visual evaluation (e.g., 'http://localhost:5173'). When provided with design domain, critics use Playwright to navigate and visually evaluate the running interface. Strongly recommended for design critiques. | |
| clis | No | Subset of native critics to run. [] = run ONLY the named clients[] (no default critics); omit to run all available. | |
| data | No | Data for research | |
| brand | No | Brand identity or design system constraints for design domain | |
| depth | No | Max depth for file_structure | |
| field | No | Field for research | |
| limit | No | Max chars/chunk | |
| scale | No | Scale for architecture/infrastructure | |
| users | No | Users for product | |
| assets | No | Assets for security | |
| budget | No | Budget for infrastructure | |
| claims | No | Claims for research | |
| cursor | No | Pagination cursor | |
| domain | Yes | Analysis domain | |
| medium | No | Design medium for design domain (web, mobile, spatial, print) | |
| models | No | Per-CLI model override. Claude honors overrides. Codex uses the Codex CLI configured/default model by default; set BRUTALIST_CODEX_ALLOW_MODEL_OVERRIDE=true to allow a codex override. Agy accepts a human-readable label ("Gemini 3.1 Pro (High)", "Claude Sonnet 4.6 (Thinking)", etc.) via its native --model flag (1.0.10+); Pro/Claude/GPT-OSS tiers require Antigravity entitlement. Omit to use each CLI's configured default. | |
| offset | No | Pagination offset | |
| resume | No | Continue conversation with a new prompt; omit for pagination/page reads | |
| target | Yes | Filesystem path to analyze (e.g., '/path/to/project' or '.'). Directs agents to the relevant part of the codebase. | |
| clients | No | Named CLI clients to run, ADDITIVE to the native critics (use clis:[] to run ONLY these). Allows multiple isolated Claude Code clients (up to 16), including custom Anthropic-compatible endpoints, in one roast. | |
| context | No | Essential context for the critique. For abstract domains (idea, architecture, security, etc.), this is the primary input describing what to evaluate. For filesystem domains, provides supplementary background (e.g., goals, constraints, team context). | |
| metrics | No | Metrics for product | |
| posture | No | Procedural posture or use context for legal domain (e.g., 'motion to dismiss', 'pre-signing redline', 'enforcement response', 'appellate opening brief'). | |
| verbose | No | Detailed output | |
| audience | No | Target audience for design domain | |
| practice | No | Practice register for legal domain — freeform (e.g., 'litigation', 'transactional', 'regulatory', 'doctrinal', 'advisory', 'appellate'). Modulates the critic's adversary geometry. | |
| timeline | No | Timeline for idea | |
| resources | No | Resources for idea | |
| compliance | No | Compliance for security | |
| context_id | No | Context ID for cached pagination or conversation continuation | |
| deployment | No | Deployment for architecture | |
| commitRange | No | Commit range for git_history | |
| competition | No | Competition for product | |
| constraints | No | Constraints for architecture | |
| mcp_servers | No | MCP servers to enable for CLI agents (e.g., ["playwright"]). Enables evidence-backed analysis via external tools. Available: playwright. Auto-enabled for design domain. | |
| runCoverage | No | Run coverage for test_coverage | |
| threatModel | No | Threat model for security | |
| jurisdiction | No | Governing jurisdiction or forum for legal domain (e.g., 'US federal', 'NY state', '9th Cir.', 'Delaware Chancery', 'EU'). | |
| force_refresh | No | Ignore cache | |
| includeDevDeps | No | Include dev deps for dependencies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It helpfully discloses that critics run in parallel, that their disagreement is the signal, and that output is adversarial feedback to be weighed rather than authoritative — useful output-nature context. But it omits operational traits the 41-param surface implies: latency/cost of spawning up to 16 clients plus native critics, and the fact that agents have Bash/WebFetch/WebSearch access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the core purpose, followed by the key behavioral caveat about evaluating adversarial output. Efficient and well-ordered, with only mild redundancy in the consolidation and evaluation-caveat lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does convey the nature of the return (panel disagreement, adversarial perspectives) and how to treat it, which is the main return-value guidance needed. It is thin on navigating the 41-parameter surface, but with 100% schema coverage that burden is largely offloaded. Adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the schema already documents all 41 parameters in depth. The description adds only the marginal note that domain drives targeted analysis, plus schema-level detail elsewhere. No compensating value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: a unified AI critique produced by a multi-critic panel running in parallel, and notes it consolidates all roast_* tools into one polymorphic API. It implicitly distinguishes itself from the debate-style sibling ('running in parallel'), though it does not name roast_cli_debate or the discover/roster siblings. Clear purpose, but sibling differentiation is only suggestive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says to 'specify domain for targeted analysis' and advises critically evaluating returned feedback, which implies usage context. However, it never states when to choose this tool over roast_cli_debate, brutalist_discover, or cli_agent_roster, nor any prerequisites. Usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy 2 CLI agents in structured adversarial debate with constitutional position anchoring. Calling agent should extract PRO/CON positions from topic before invoking. IMPORTANT: Critically evaluate all debate output — positions are assigned, not necessarily held. Weigh each argument's validity independently before presenting to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | Yes | The debate topic | |
| agents | No | Two specific debaters to use. | |
| cursor | No | ||
| models | No | Model overrides for specific agents. Codex uses the Codex CLI configured/default model by default unless BRUTALIST_CODEX_ALLOW_MODEL_OVERRIDE=true. Agy honors the model label via its native --model flag (1.0.10+). | |
| offset | No | ||
| resume | No | Continue debate with a new prompt; omit for pagination/page reads | |
| rounds | No | Number of debate rounds (default: 3) | |
| target | No | Filesystem path to analyze (e.g., '/path/to/project' or '.'). Directs agents to the relevant part of the codebase. | |
| clients | No | NOT SUPPORTED in debate. Use `agents` to pick the two debaters; custom Claude-routed clients (e.g. GLM) run only via `roast`. | |
| context | No | Essential context for the debate — the substantive background, constraints, and details that shape the argument. | |
| verbose | No | ||
| context_id | No | Context ID for cached pagination or debate continuation | |
| conPosition | Yes | The CON thesis to defend (extracted by calling agent) | |
| mcp_servers | No | MCP servers to enable for debate agents (e.g., ["playwright"]). Available: playwright | |
| proPosition | Yes | The PRO thesis to defend (extracted by calling agent) | |
| force_refresh | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must fully disclose behavior. It reveals that positions are assigned and not necessarily held, which is a key behavioral trait. However, it lacks detail on side effects, costs, or what 'constitutional position anchoring' entails. Some behavioral context is provided, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three front-loaded sentences. The first sentence states the purpose, the second gives an instruction, and the third warns about output interpretation. It wastes no words but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 17 parameters, nested objects, and no output schema, the description lacks completeness. It does not explain pagination parameters (cursor, offset, context_id), debate flow, return values, or configuration of agents/models. The schema descriptions help, but the tool description itself is insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, so the schema already documents most parameters. The description adds no significant per-parameter detail beyond what is in the schema, aside from emphasizing extraction of pro/con positions. This meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: deploying two CLI agents in a structured adversarial debate with constitutional position anchoring. This distinguishes it from siblings like 'roast' (likely single-agent) and 'cli_agent_roster' (listing agents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific usage instructions: 'Calling agent should extract PRO/CON positions from topic before invoking' and advises critical evaluation of output since positions are assigned. It does not explicitly mention when not to use or alternatives, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.18.10brutalist_discoverroastv1.18.9brutalist_discoverroastv1.18.3roast4 fields changedInput schema / properties / clientsAdded value: +{
+ "description": "Named CLI clients to run, ADDITIVE to the native critics (use clis:[] to run ONLY these). Allows multiple isolated Claude Code clients (up to 16), including custom Anthropic-compatible endpoints, in one roast.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "authToken": {
+ "description": "Bearer token for ANTHROPIC_AUTH_TOKEN. Prefer authTokenEnv for shared configs.",
+ "type": "string"
+ },
+ "authTokenEnv": {
+ "description": "Environment variable name containing the bearer token.",
+ "type": "string"
+ },
+ "baseUrl": {
+ "description": "Claude-compatible endpoint base URL for ANTHROPIC_BASE_URL (http(s) only). Presence marks the client 'routed': isolated from native credentials and hardened (no web egress/MCP) by default.",
+ "format": "uri",
+ "type": "string"
+ },
+ "configDir": {
+ "description": "Per-client CLAUDE_CONFIG_DIR for Claude Code state isolation. Defaults to ~/.brutalist/claude-clients/<id> for routed clients.",
+ "type": "string"
+ },
+ "containment": {
+ "description": "Tool/sandbox policy. 'hardened' (DEFAULT for any routed/custom-endpoint client) additionally denies WebFetch, WebSearch, and all MCP servers. 'standard' restores the native tool surface — only for an endpoint you fully trust.",
+ "enum": [
+ "hardened",
+ "standard"
+ ],
+ "type": "string"
+ },
+ "env": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "description": "Additional per-client environment variables (applied last; override resolved values).",
+ "type": "object"
+ },
+ "id": {
+ "description": "Stable display id for this CLI client, e.g. claude-native or glm.",
+ "maxLength": 80,
+ "minLength": 1,
+ "type": "string"
+ },
+ "includeProcessAuth": {
+ "description": "Routed clients are isolated by default (no native Claude credentials). Set true to ALSO inherit the process ANTHROPIC_API_KEY/CLAUDE_CODE_OAUTH_TOKEN into this client; set false to force isolation on an otherwise-native client.",
+ "type": "boolean"
+ },
+ "mcpServers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "model": {
+ "description": "Per-client model override.",
+ "type": "string"
+ },
+ "provider": {
+ "default": "claude",
+ "description": "Underlying CLI provider.",
+ "enum": [
+ "claude",
+ "codex",
+ "agy"
+ ],
+ "type": "string"
+ },
+ "smallFastModel": {
+ "description": "Claude Code small/fast model override for ANTHROPIC_SMALL_FAST_MODEL. Defaults to `model` for routed clients so a gateway never sees Claude's built-in haiku name.",
+ "type": "string"
+ },
+ "timeout": {
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "workingDirectory": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "maxItems": 16,
+ "type": "array"
+}Input schema / properties / clis / descriptionPrevious value: -"Subset of critics to run."New value: +"Subset of native critics to run. [] = run ONLY the named clients[] (no default critics); omit to run all available."Input schema / properties / clis / minItemsPrevious value: -1New value: +0Input schema / properties / models / descriptionPrevious value: -"Per-CLI model override. Claude honors overrides. Codex uses the Codex CLI configured/default model by default; set BRUTALIST_CODEX_ALLOW_MODEL_OVERRIDE=true to allow a codex override. Agy accepts a human-readable label (\"Gemini 3.1 Pro (High)\", \"Claude Sonnet 4.6 (Thinking)\", etc.) via settings.json swap under flock(2); Pro/Claude/GPT-OSS tiers require Antigravity entitlement. Omit to use each CLI's configured default."New value: +"Per-CLI model override. Claude honors overrides. Codex uses the Codex CLI configured/default model by default; set BRUTALIST_CODEX_ALLOW_MODEL_OVERRIDE=true to allow a codex override. Agy accepts a human-readable label (\"Gemini 3.1 Pro (High)\", \"Claude Sonnet 4.6 (Thinking)\", etc.) via its native --model flag (1.0.10+); Pro/Claude/GPT-OSS tiers require Antigravity entitlement. Omit to use each CLI's configured default."roast_cli_debate2 fields changedInput schema / properties / clientsAdded value: +{
+ "description": "NOT SUPPORTED in debate. Use `agents` to pick the two debaters; custom Claude-routed clients (e.g. GLM) run only via `roast`.",
+ "type": "array"
+}Input schema / properties / models / descriptionPrevious value: -"Model overrides for specific agents. Codex uses the Codex CLI configured/default model by default unless BRUTALIST_CODEX_ALLOW_MODEL_OVERRIDE=true. Agy is Flash-pinned (no --model flag); field ignored."New value: +"Model overrides for specific agents. Codex uses the Codex CLI configured/default model by default unless BRUTALIST_CODEX_ALLOW_MODEL_OVERRIDE=true. Agy honors the model label via its native --model flag (1.0.10+)."v1.14.0brutalist_discovercli_agent_rosterroastroast_cli_debateScored across 4 tools
roast and roast_cli_debate overlap: both deliver adversarial AI critique via CLI agents, with the debate being a specialized variant. brutalist_discover and cli_agent_roster are both meta/informational tools that could be confused about their distinct roles, though descriptions do clarify them somewhat.
Names mix conventions: a bare verb (roast), a prefixed verb (roast_cli_debate), and two differently-prefixed nouns (brutalist_discover, cli_agent_roster). The roast_ prefix appears on unrelated tools and prefix families (brutalist_, cli_, roast_) don't follow a single predictable pattern.
Four tools is slightly thin but reasonable for a focused critique/debate server. The presence of a discovery tool hints at a larger intended toolset that isn't surfaced, but the count itself isn't problematic.
The surface covers single-panel critique, multi-agent debate, agent discovery, and roster inspection — a fairly full lifecycle for adversarial analysis. Minor gap: discovery implies additional brutalist tools that aren't actually exposed here.
Multi-LLM council: 25+ frontier models in parallel, consensus scoring, verdict-first code review.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Agentic code review, no signup to try: reality gates + frontier-model review, with veto.
Code review by AI models from different companies, usually two. Shows where they agree and disagree.
