What Covenant Guard MCP server does
Covenant Guard MCP server provides an MCP-facing path into Covenant, an agent infrastructure project built around the covenantd Rust daemon. The daemon sits between agent applications and the host operating system, owning local state and mediating operations through permissions, runtime dispatch, memory stores, identity controls, and audit logging.
For the Coding Agents category, the relevant use case is supervising longer-running engineering work rather than giving an agent unrestricted access to the machine. Covenant models requests as intents, checks signed capabilities at dispatch time, records activity in an append-only audit chain, and applies runtime budget controls. The project also includes CLI, IPC, local HTTP, web-console, and A2A surfaces, although this listing focuses on its MCP integration.
How it works
Build and start covenantd, then register an agent under $COVENANT_HOME/agents/. The daemon loads registered agents during startup and provides shared state for the CLI and operator console. The README identifies MCP as one of the communication surfaces that can reach the daemon, but it does not document a separate MCP package, transport configuration, or list of MCP tool names.
Covenant normalizes incoming requests as intents. Runtime dispatch can enforce budgets using projection-tick preemption and a wall-clock backstop configured through cpu_ms_per_task. Permissions use signed capabilities with scope validation, expiration, revocation, and enforcement when work is dispatched. Audit events are stored as append-only JSONL with hash-chain integrity reporting, retention controls, signed actions, and audit-root attestations.
Setup and configuration
The documented local setup requires Rust tooling and a source checkout. Build the workspace from agent-os with Cargo, excluding the settlement program, create ~/.covenant/agents, copy the example agent there, and launch covenantd. The CLI can then grant capabilities such as memory.write and intent.subscribe, or submit an intent.
The repository also provides a Next.js operator console. Running it requires changing to agent-os/covenant-web, installing dependencies with pnpm, and starting the development server. The console proxies the daemon’s HTTP gateway and supplies the operator bearer token server-side.
Tools and capabilities
The documented system capabilities include:
- Intent submission and daemon-mediated dispatch.
- Signed capability grants, expiry, revocation, and scope checks.
- SQLite-backed working, episodic, and long-term memory.
- Local Ed25519 identity, operator tokens, peer registration, and revocation.
- Append-only audit events, integrity reports, signed actions, and provenance records.
- Runtime budget enforcement and trusted-local subprocess execution.
- Local resource receipts and settlement-related protocol components.
The repository describes an opt-in Linux gVisor runner, but also states that production-grade sandboxing for hostile agent code remains on the roadmap. The deployed Solana settlement program and TypeScript SDK cover on-chain instructions such as agent registration, staking, escrow, credit purchases, and receipt anchoring; those functions should not be assumed to be MCP tools without additional documentation.
Limitations and notes
Covenant Guard MCP server is documented as part of a broader local control plane, not as an independently packaged MCP service with a published tool catalog. It also distinguishes live-tested local control-plane functionality from unfinished production features: hostile-code sandboxing, networked multi-peer operation, and the daemon-driven economic lifecycle are not described as production-ready.
The public sandbox can be tried without a local installation, but its state resets every 12 hours. Local operation requires compiling the Rust workspace and running the daemon yourself.