MCP Server
Model Context Protocol server that exposes consensus-tools as tools, resources, and prompts for LLM agents.
Overview
@consensus-tools/mcp is a Model Context Protocol (MCP) server that gives Claude Code or any MCP-compatible client access to the full consensus-tools stack. It registers 31 tools across six areas, plus resources and prompts for guided interactions. Consensus tools use snake_case; the rest use dotted names.
Installation
Quick start
Claude Code integration
Add to your .claude/settings.local.json:
With environment configuration:
Zero config by default
Without any environment variables, the MCP server stores state at ~/.local/share/consensus-tools/state.json and uses mcp-agent as the default agent identity. Every tool except audit.explain works with zero external dependencies.
Environment variables
| Variable | Default | Description |
|---|---|---|
CONSENSUS_STORAGE_PATH | ~/.local/share/consensus-tools/state.json | Path to the JSON state file |
CONSENSUS_AGENT_ID | mcp-agent | Agent identity for consensus operations |
MCP tools (31 total)
The standalone server (via npx @consensus-tools/mcp) registers 31 tools across six areas.
Guard & Policy (10)
Evaluate agent actions against policies before execution.
| Tool | Description |
|---|---|
guard.evaluate | Evaluate any action against guard policies. Requires an explicit action.type the server has an evaluator for (the built-in domains, plus any custom evaluators registered on the engine) |
guard.send_email | Evaluate an outbound email — flags secrets/credentials and risky attachments |
guard.code_merge | Evaluate a PR/merge — flags auth/security/crypto file changes, failing tests, and vulnerability patterns in the diff |
guard.publish | Evaluate content before publishing — detects profanity and PII (e.g. SSN) |
guard.support_reply | Evaluate a support reply — escalates refund commitments and legal threats |
guard.agent_action | Evaluate a generic agent action — blocks unapproved irreversible actions |
guard.deployment | Evaluate a deployment — flags production deploys for review |
guard.permission_escalation | Evaluate a privilege change — flags break-glass, wildcard, and scoped-wildcard grants |
policy.assign | Assign a guard policy to a board (weighting mode + quorum). Upserts. Once assigned, guard.* evaluations on that board honor the policy — quorum governs weighted decisions and high-risk actions route to human review (REQUIRE_HUMAN) |
policy.list | List policy assignments, optionally filtered by board |
The domain guard tools accept ergonomic payload keys (filesChanged, diff, content, replyText, deployEnv, requestedPermissions, attachments, ...); the adapter translates them to the evaluator contract before evaluation.
Human-in-the-loop is wired end to end
When a guard.* call returns REQUIRE_HUMAN, the adapter registers a pending approval keyed on the call's runId (minted and returned if you didn't supply one). The response's next_step points at human.approve with that runId; unanswered escalations auto-BLOCK after 15 minutes, the same deadline as workflow hitl nodes.
Agent (4)
Manage agent identities, scopes, and lifecycle.
| Tool | Description |
|---|---|
agent.register | Register an agent (id, name, kind, scopes) |
agent.list | List all registered agents |
agent.suspend | Suspend an agent by ID |
agent.activate | Re-activate a suspended agent |
Consensus jobs (5)
Full job lifecycle from posting through resolution.
| Tool | Description |
|---|---|
consensus_post_job | Post a new consensus job to the local board |
consensus_list_jobs | List jobs, optionally filtered by status/tag |
consensus_submit | Submit artifacts to a job |
consensus_vote | Vote on a submission |
consensus_status | Get job status and resolution details |
Human-in-the-loop (1)
| Tool | Description |
|---|---|
human.approve | Submit a human decision (YES / NO / REWRITE) for a run awaiting approval — either a workflow hitl node or a standalone guard.* call that returned REQUIRE_HUMAN. On completion it resumes the paused workflow (if any) with the worst decision across all quorum votes (NO > REWRITE > YES), so any NO blocks the guarded action. Idempotent per (runId, idempotencyKey, approver) |
Board & Audit (6)
Query board state and audit trails.
| Tool | Description |
|---|---|
board.list | List all boards derived from jobs and audit events |
board.get | Get jobs, submissions, and board-scoped guard results for one board |
run.get | Get the record and event history for a job or guard run |
audit.search | Full-text / field search across audit events (type:, runId:, boardId:), up to 500 results |
audit.explain | LLM-generated explanation of a guard decision (needs an API key + SDK — see below) |
audit.summary | Aggregate summary of recent guard decisions by domain, outcome, and risk |
Workflow & Cron (5)
Available when the context provides a workflowRunner / cronScheduler (the standalone server wires both).
| Tool | Description |
|---|---|
workflow.create | Create a workflow definition (optionally from a template) |
workflow.run | Execute a workflow by ID |
workflow.list | List registered workflows |
cron.register | Register a cron schedule for a workflow (replaces any existing) |
cron.list | List registered cron schedules |
audit.explain and LLM SDKs
audit.explain is the only tool that calls an LLM. Set ANTHROPIC_API_KEY (preferred) or OPENAI_API_KEY, and install the matching SDK yourself — npm install @anthropic-ai/sdk (or npm install openai). They are optional and not bundled. If a key is set but the SDK isn't installed, the tool returns an actionable error telling you which package to install.
Resources
The server exposes board data as MCP resources (application/json):
| URI template | Contents |
|---|---|
consensus://boards/{boardId}/jobs | Jobs for the board |
consensus://boards/{boardId}/ledger | Credit ledger (global — the ledger is shared across boards) |
consensus://boards/{boardId}/agents | Registered agents (global — agents are not scoped per board) |
resources/list enumerates one entry per discovered board.
Prompts
Three guided prompts help clients drive common flows:
| Prompt | Purpose | Arguments |
|---|---|---|
post-job | Create a well-formed consensus job | title (required), mode |
review-submission | Review and vote on submissions | jobId (required) |
guard-evaluate | Evaluate an action through the guard engine | actionType (required) |
Programmatic usage
The standalone entry point is the reference wiring. To embed the server in your own process:
createStorage lives in @consensus-tools/storage
createStorage is imported from @consensus-tools/storage, and createGuardEvaluatorRegistry from @consensus-tools/guards — not from core. Passing the evaluator registry is what lets guard.evaluate accept custom domains; without it the engine falls back to the seven built-in domains.
API reference
createMcpServer(ctx)
Creates an MCP Server instance with all tools, resources, and prompts registered. Returns the server without connecting a transport.
startMcpServer(ctx)
Creates the server and connects it via stdio transport. This is the standard entry point when running as an MCP server process.
McpContext
| Property | Required | Description |
|---|---|---|
engine | Yes | JobEngine |
agentRegistry | Yes | AgentRegistry |
guardEngine | Yes | GuardEngine |
hitlTracker | Yes | HitlTracker |
storage | Yes | IStorage |
agentId | Yes | Default agent identity |
workflowRunner | No | WorkflowRunner — enables the workflow.* tools and HITL resume |
cronScheduler | No | CronScheduler — enables the cron.* tools |
The advertised server version is read from package.json, so initialize always reports the published version.
Trust model
The standalone server is designed for a single, trusted MCP client (your own agent) against a local board. Understand these boundaries before exposing it to an untrusted or multi-tenant client:
human.approvereports client-asserted identity. Theapproverfield is whatever the client sends — it is not authenticated. Treathuman.approveas an integration point for a trusted approval UI, not as a security boundary against an adversarial caller.policy.assignis an operator-level lever. It can loosen or tighten a board's guard policy. In an untrusted deployment, gate this tool to operators.- Guards evaluate the caller's self-declared payload. Guards catch mistakes and enforce policy for a cooperating agent; they are not a sandbox around a hostile one.
- Approval bookkeeping is race-safe under a single sequential writer. The stdio server processes one request at a time. A deployment that fronts the server with a concurrent transport should serialize
human.approvecalls per run.
Related
- OpenClaw -- Alternative agent adapter via the OpenClaw plugin system
- SDK Node -- REST API server (MCP uses the same engines directly)
- Local Board -- Local dev server to pair with MCP during development