Panella MCP server

Panella

<!-- mcp-name: io.github.panellatech/panella -->

Governed, self-hosted memory for AI agents.

Your agents write to a memory your company actually controls: a governed write is proposed, approved by an authorized approver, and made durable only against a chain-verified approval receipt — never a silent background rewrite. A standard MCP server: Claude Code, Claude Desktop, Cursor, or any MCP client connects with one line. Default-deny, fully auditable, runs on your own box. Apache-2.0.

uv tool install panella
panella up --yes --home ~/panella-box   # one command: box + tokens + governance,
                                        # then it prints your `claude mcp add …` connect line

Your agent proposes a memory → it queues → you approve it (CLI, console, or API) → your agent recalls it next turn. No governed write becomes durable truth without an authorized approver and a committed, chain-verified approval receipt: approve through the CLI, console, or API and the decision is recorded before it takes effect — and whatever path stamped a row, the finalizer refuses to make it durable without a receipt it can verify.

Two ways to build agent memory

Most memory layers consolidate in the background: memories are merged, summarized, and updated automatically. That design is a deliberate, reasonable choice for personal assistants — speed over ceremony.

Panella takes the other branch, for teams and companies: governed writes queue as proposals, a named person approves them, and the decision itself is kept as evidence — so when someone asks "who decided this was true?", the system has an answer it can prove. (Governance is per wing/room configuration: a deployment can leave a scope ungoverned, and those writes are direct by that explicit choice — the guarantees below are about the governed path.)

submits lands until a person approves it.

• Default-deny agent writes — an agent's MCP write can only ever propose; nothing an agent

approval token is the approver identity, verified during approval. An agent cannot approve its own memory.

• Two-factor approval — the agent's bearer is routing admission only; a separate operator-held

decision is appended to a tamper-evident hash chain before it takes effect; and no governed write becomes durable — whatever path stamped it — unless the finalizer verifies such a receipt: chain intact from genesis, the recorded decision/approver, and a fingerprint of the exact approved bytes. No verifiable receipt, no write.

• Receipt-gated durability — on the box's own approval surfaces (HTTP, MCP, CLI) every approval

it, stamped server-side at enqueue (never caller-supplied; a hand-crafted queue row is simply unattributed), recorded in the chain-verified approval receipt, and carried from that verified receipt into the durable memory. The approver sees who is asking before deciding, and the durable memory records the proposer alongside who approved it.

• Attributed proposals — every newly proposed candidate carries the agent profile that proposed

indistinguishable not-found, never a cross-tenant existence oracle.

• Tenant-isolated — a second agent or member reads only its own scope; foreign records return an

approve, recall — runs end-to-end over MCP, and the approval boundary is the credential, not the transport.

• MCP-native — a standard MCP server (Streamable HTTP). The governed loop — submit, queue,

• Runs on your box — Docker Compose, SQLite, loopback-only by default. Your data, your bytes.

Quickstart

Shortened. The full README is on GitHub.