Sage

What l33tdawg/sage MCP server does

The l33tdawg/sage MCP server provides persistent memory infrastructure for AI agents. Memories can carry attribution and confidence, pass through consensus validation, be recalled semantically, and decay over time. The system is designed for institutional memory that remains available across conversations and agent sessions.

Beyond memory, SAGE supports durable tasks assigned to specific agents, a unified inbox, retained replies, runtime handoff, access groups, ownership checks, classification controls, and bounded federation between separate SAGE chains. These functions support multi-agent workflows where assignment, claiming, completion, and reply are distinct states.

How it works

A SAGE node accepts requests from agents through MCP, SDK, or REST and applies authentication and local policy before processing them. Consensus state is maintained through CometBFT and ABCI, with BadgerDB serving as the authoritative chain store. Memory content and vectors are projected at commit time into SQLite for personal deployments or PostgreSQL with pgvector for clusters.

Personal mode uses one CometBFT validator with a per-node memory auto-voter, so it does not provide Byzantine redundancy. Multi-validator deployments use a shared chain. Separate chains can be connected through explicit federation policies that limit reading and copying; federation does not automatically grant local membership or write access.

Setup and configuration

The project can be built from source with Go 1.25.13 or newer. The documented source workflow builds the sage-gui binary, uses sage-gui setup to generate MCP configuration for a selected AI, and starts the service with sage-gui serve. The service and dashboard use port 8080 by default.

Release downloads are available for macOS, Windows, and Linux. A Docker image is published at ghcr.io/l33tdawg/sage. For a containerized stdio connection, the MCP process runs inside the already-running SAGE container and receives SAGE_PROVIDER, SAGE_PROJECT, and SAGE_IDENTITY_PATH. The SAGE data directory should remain mounted so agent keys and ledger state persist.

The l33tdawg/sage MCP server also exposes HTTP MCP endpoints at /v1/mcp/sse and /v1/mcp/streamable; these endpoints require a bearer token or OAuth. The base URL at port 8080 is a REST endpoint, not an unauthenticated MCP endpoint.

Tools and capabilities

The documented capability set includes:

• Governed memory with validation, semantic recall, confidence, and lifecycle controls
• Durable, idempotent tasks assigned to exact agents
• Unified inboxes for local or federated requests and assignment notices
• Retained replies and reply pagination
• Session- and revision-fenced runtime handoff
• Enrollment, roles, profiles, ownership, access groups, grants, and classification checks
• Explicit federation with bounded read and copy policies
• Recovery snapshots, in-place upgrades, and retained message claims

The repository description reports 13 MCP tools, while the excerpt does not enumerate every tool name or parameter.

Limitations and notes

Consensus acceptance and block inclusion are different events. Agent requests and results are treated as untrusted data and cannot expand the user’s instructions. Wake notifications are hints without payload, delivery guarantees, or claim evidence.

Adding more agents in personal mode does not create additional consensus voters. Runtime handoff keeps work within the same signed agent identity and does not reassign a task to another agent. HTTP MCP requires authentication, and a separate docker run ... mcp container is not the documented setup because its localhost network is isolated from the running SAGE node.

The l33tdawg/sage MCP server is open source in a public GitHub repository, but the provided material does not state its license.