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

pnpm add @consensus-tools/mcp

Quick start

Claude Code integration

Add to your .claude/settings.local.json:

{
  "mcpServers": {
    "consensus-tools": {
      "command": "npx",
      "args": ["@consensus-tools/mcp"]
    }
  }
}

With environment configuration:

{
  "mcpServers": {
    "consensus-tools": {
      "command": "npx",
      "args": ["@consensus-tools/mcp"],
      "env": {
        "CONSENSUS_STORAGE_PATH": "/path/to/state.json",
        "CONSENSUS_AGENT_ID": "my-agent"
      }
    }
  }
}

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

VariableDefaultDescription
CONSENSUS_STORAGE_PATH~/.local/share/consensus-tools/state.jsonPath to the JSON state file
CONSENSUS_AGENT_IDmcp-agentAgent 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.

ToolDescription
guard.evaluateEvaluate 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_emailEvaluate an outbound email — flags secrets/credentials and risky attachments
guard.code_mergeEvaluate a PR/merge — flags auth/security/crypto file changes, failing tests, and vulnerability patterns in the diff
guard.publishEvaluate content before publishing — detects profanity and PII (e.g. SSN)
guard.support_replyEvaluate a support reply — escalates refund commitments and legal threats
guard.agent_actionEvaluate a generic agent action — blocks unapproved irreversible actions
guard.deploymentEvaluate a deployment — flags production deploys for review
guard.permission_escalationEvaluate a privilege change — flags break-glass, wildcard, and scoped-wildcard grants
policy.assignAssign 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.listList 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.

ToolDescription
agent.registerRegister an agent (id, name, kind, scopes)
agent.listList all registered agents
agent.suspendSuspend an agent by ID
agent.activateRe-activate a suspended agent

Consensus jobs (5)

Full job lifecycle from posting through resolution.

ToolDescription
consensus_post_jobPost a new consensus job to the local board
consensus_list_jobsList jobs, optionally filtered by status/tag
consensus_submitSubmit artifacts to a job
consensus_voteVote on a submission
consensus_statusGet job status and resolution details

Human-in-the-loop (1)

ToolDescription
human.approveSubmit 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.

ToolDescription
board.listList all boards derived from jobs and audit events
board.getGet jobs, submissions, and board-scoped guard results for one board
run.getGet the record and event history for a job or guard run
audit.searchFull-text / field search across audit events (type:, runId:, boardId:), up to 500 results
audit.explainLLM-generated explanation of a guard decision (needs an API key + SDK — see below)
audit.summaryAggregate 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).

ToolDescription
workflow.createCreate a workflow definition (optionally from a template)
workflow.runExecute a workflow by ID
workflow.listList registered workflows
cron.registerRegister a cron schedule for a workflow (replaces any existing)
cron.listList 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 templateContents
consensus://boards/{boardId}/jobsJobs for the board
consensus://boards/{boardId}/ledgerCredit ledger (global — the ledger is shared across boards)
consensus://boards/{boardId}/agentsRegistered 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:

PromptPurposeArguments
post-jobCreate a well-formed consensus jobtitle (required), mode
review-submissionReview and vote on submissionsjobId (required)
guard-evaluateEvaluate an action through the guard engineactionType (required)

Programmatic usage

The standalone entry point is the reference wiring. To embed the server in your own process:

import { startMcpServer, createMcpServer, type McpContext } from "@consensus-tools/mcp";
import {
  LocalBoard, AgentRegistry, GuardEngine, HitlTracker,
} from "@consensus-tools/core";
import { createStorage } from "@consensus-tools/storage";
import { createGuardEvaluatorRegistry } from "@consensus-tools/guards";

const storage = await createStorage(config);
const board = new LocalBoard(config, storage);
await board.init();

const agentRegistry = new AgentRegistry(storage);
const ctx: McpContext = {
  engine: board.engine,
  agentRegistry,
  guardEngine: new GuardEngine({ storage, agentRegistry, evaluatorRegistry: createGuardEvaluatorRegistry() }),
  hitlTracker: new HitlTracker({ storage }),
  storage,
  agentId: "my-agent",
  // workflowRunner / cronScheduler are optional — provide them to enable
  // the workflow.* and cron.* tools.
};

// Option 1: start on stdio (typical for MCP)
await startMcpServer(ctx);

// Option 2: get the Server instance for a custom transport
const server = createMcpServer(ctx);

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

PropertyRequiredDescription
engineYesJobEngine
agentRegistryYesAgentRegistry
guardEngineYesGuardEngine
hitlTrackerYesHitlTracker
storageYesIStorage
agentIdYesDefault agent identity
workflowRunnerNoWorkflowRunner — enables the workflow.* tools and HITL resume
cronSchedulerNoCronScheduler — 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.approve reports client-asserted identity. The approver field is whatever the client sends — it is not authenticated. Treat human.approve as an integration point for a trusted approval UI, not as a security boundary against an adversarial caller.
  • policy.assign is 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.approve calls per run.
  • 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