Mandare

What Mandare MCP server does

Mandare MCP server provides an MCP interface to selected Mandare accountability operations. The repository describes four MCP capabilities: verifying the ledger, checking budgets, issuing credentials, and killing an agent. These operations are intended for local oversight of an agent fleet rather than for exposing model-provider functionality directly.

Mandare records activity in an append-only ledger. Entries are hash-chained and signed by the gateway door, while budget counters and revocation state are projections that can be checked by replaying the ledger. Refused actions are recorded too, so a denied spend or other policy decision remains part of the audit history.

The surrounding Mandare stack also supports signed agent identity through Passports, signed authority through Mandates, and a kill switch that does not depend on a remote service. External witnessing and public anchoring can help detect truncated or rewritten ledger history. The repository states that raw prompts and responses stay on the local machine.

How it works

The MCP server runs as a stdio process and reads the ledger location from its environment. By default, the ledger path is ./mandare-ledger.db; MANDARE_LEDGER_DB can point to another database. The server is therefore suited to an MCP client operating alongside a local Mandare installation.

Verification checks the ledger chain and can establish whether the recorded counters match a replay of ledger entries. In the Docker demonstration, verification also checks witnessed head history. The no-Docker demonstration does not include a witness unless one is started separately, so its verification cannot detect entries removed from the end of the ledger without a previously saved head.

Mandare's gateway applies a fail-closed model: without a mandate, spending is refused; if the ledger is unavailable, action is refused; and high-value actions refuse when the witness is unavailable. The kill switch remains independent of remote witnessing. These enforcement behaviors belong to the broader Mandare stack that the MCP tools inspect or control.

Setup and configuration

The repository offers an npm-based installation path for the CLI and MCP server:

npm i -g @mandarelabs/cli
npx -y @mandarelabs/mcp-server

The MCP process reads MANDARE_LEDGER_DB, defaulting to ./mandare-ledger.db. A full local setup can instead be run from a checkout with Docker Compose, or without Docker using Node.js 22.13 or newer and pnpm 10. The Docker quickstart starts the gateway, witness, and dashboard; the repository's demo uses a bundled mock provider and does not require API keys.

Mandare MCP server is configured through environment state rather than a documented client-specific configuration in the supplied material. The broader installation stores vault, agent credential, and door-key data in local locations, with the vault master key using the operating system keychain by default.

Tools and capabilities

• Verify the integrity and replay-derived state of the ledger.
• Inspect agent budget information.
• Issue agent credentials through Mandare's issuance flow.
• Kill a runaway agent.
• Operate over stdio for MCP client integration.
• Read a locally configured SQLite ledger through MANDARE_LEDGER_DB.

These capabilities expose oversight and control functions; the supplied material does not document individual MCP tool names or argument schemas.

Limitations and notes

Mandare MCP server is local-first, but the strength of verification depends on the surrounding deployment. A no-witness setup cannot identify entries dropped from the end of the ledger unless verification receives a saved previous head. The repository describes the external audit as pending, despite reporting AI-assisted review and regression testing.

The project uses AGPL-3.0-only for the main project, while certain embeddable packages are separately licensed. The supplied README does not provide a complete MCP client compatibility matrix or detailed tool schemas, so client configuration and exact arguments should be confirmed in the repository documentation before deployment.