This server exposes a personal memory brain to AI agents via MCP, enabling identity-grounded recall, persona simulation, guardrail governance, snapshots, and validation.
celebrum.recall — Retrieve memories grounded in identity and evidence, with configurable result count and optional identity grounding.
celebrum.simulate — Run a "what if" scenario through the persona model to get stance, reasoning, and value conflicts.
celebrum.propose_guardrail — Propose persona guardrail adaptations tiered by risk (low/medium/high).
celebrum.approve_guardrail — Approve or reject a pending/active guardrail by ID; high-tier approvals require a human identity.
celebrum.snapshot — Return a full brain snapshot covering persona, memory, truth, guardrails, and tensor state.
celebrum.validate — Run the six-check neural validation harness (BRIDGE, ID-RAG, PGMem, PTM, DPDP, performance).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Celebrum MCP recall what I believe about privacy from my memories"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local-first artificial brain. Celebrum grows a permanent personal memory (a neuron/synapse knowledge graph), learns a Persona Model from it, guards every autonomous action behind a consent-first Guardrail Engine, and answers through remembering who you are — not just what you typed.
Not just code — a memory. For my love, Celebrity
"What we love most, we fear about them most — and it may be must."
"A Valuable gift made for a valuable celebrity — no quantifying."
Built in 8 hours.
Memory Graph (graphdb) — neurons and synapses stored in SQLite. Tiered, time-decaying recall: core identity memories (2-year half-life) survive while ephemeral details fade (BRIDGE-styled stable updates).
Identity-grounded recall — queries are recalled through the statement graph of your identity (beliefs, traits, values, relationships), so the brain answers as you, the way contemporary identity-rag systems do.
Evidential persona (PGMem) — persona signals are only believed when linked to the preference/decision memories that ground them. No mystical "voice generator" — values come from traced evidence edges.
PersonalTensorMemory (PTM) — a ~2 MB feature-hashed personal tensor (no plaintext) for latency-critical similarity and offline drift checks.
Truth Engine (Satya) — a veracity layer, a truth index, and a contradiction ratio over the graph; integration pauses when truth degrades (the same review-gate celebrated by the SatyaSandha way).
Guardrail Engine — six built-in guards (consent, reversibility, right-to-erasure, human approval for high-tier, append-only audit, data minimization). Nothing autonomous happens without passing a guard.
Simulation — stance + value-conflict inference before any action, so the brain checks what would I really think? against its own persona.
Inference as a service — a standards-based MCP server and a zero-dependency web dashboard.
Related MCP server: personal-knowledge
Pure Python 3.9+ standard library only. No compiled deps.
pip install . # or: pipx install . / uv tool install .
celebrum init --demo # first brain, seeded with an example memory export
celebrum gui # open the dashboard at http://localhost:8477
celebrum mcp # stdio JSON-RPC server for AI agentsWorks on Linux, macOS, Windows, Raspberry Pi, and Android (Termux).
celebrum init --demo # create a brain, load demo memories
celebrum recall "privacy" # identity-grounded recall
celebrum persona # show persona + evidence trace
celebrum simulate "should we log every keystroke?" # stance + value conflicts
celebrum truth # veracity / truth index / contradictions
celebrum validate # run the full neural validation harness
celebrum propose # guardrail proposals (truth review gate)
celebrum guardrails # view + approve/revert proposals
celebrum status # one-screen summaryIngest real memories (explicit consent required, audit-logged — DPDP/GDPR):
celebrum ingest duet export.json # Duet-style consented memory export
celebrum ingest html ~/notes/friend.html # extracts neuron/synapse fragments
celebrum ingest web https://... # SSRF-guarded, <=5MB, consent-gatedcelebrum gui starts a local dashboard (default http://localhost:8477):
Persona — style/values/heuristics/tone with evidence traces
Memory — recall by topic, browse the neuron/synapse graph (the "OI Neural Research Graph" pattern, adopted from the matruswara sources)
Simulate — stance + conflict drafts against the persona
Guardrails — propose / approve / reject / revert (high tier = human only)
Truth — veracity, truth index, contradiction ratio
Graph — force-directed SVG of neurons <-> synapses
Audit — the append-only compliance trail
Validate — run the six-check neural harness from the browser
Expose your brain to any MCP client (Claude, Cursor, agents):
celebrum.recall identity-grounded memory recall
celebrum.simulate stance + value-conflict simulation
celebrum.propose_guardrail propose a guardrail change (audited)
celebrum.approve_guardrail approve (high tier requires a human identity)
celebrum.snapshot snapshot + drift comparison
celebrum.validate run the neural validation harnesscelebrum validate runs the research-backed harness; every run is audited:
Check | Source | Pass |
Bridge-drift-bound | ICML 2026 poster (tiered memory drift bound) | Pass |
Identity-recall | ID-RAG (arXiv:2509.25299) | Pass |
Evidential validity | PGMem (arXiv:2608.01708) | Pass |
Tensor memory | Latent Personal Memory (arXiv:2606.20911) | Pass |
Guardrail conformance | DPDP s.6 + llm-guardrails | Pass |
Recall latency @10k | SRS 3.3 | Pass |
Continuous scorecard (measured on a seeded brain):
Area | Score | Grade |
Cognitive Fidelity | 0.85 | A- |
Memory Persistence | 0.84 | A- |
Guardrail Adaptability | 0.78 | B+ |
Persona Consistency | 0.81 | B+ |
Privacy & Compliance | 0.90 | A |
Integration Readiness | 0.85 | A- |
Overall | 0.84 | A- |
See docs/VALIDATION.md for the check mapping, the scorecard details, and the
"Similar research in India" comparison (BrainTwin-AI, BITS Pilani CDT,
PTM, XMem, Eka, Kemory/SeKondBrain, Engram, Cognitwin). See docs/SRS.md for
the full spec.
celebrum/ the brain (packages)
store.py SQLite node/edge store + append-only audit
memory.py neuron/synapse MemoryGraph, decay, recall
persona.py PersonaModel + appeal/feedback, identity closure
tensor.py feature-hashed PersonalTensor (no plaintext)
truth.py Satya: veracity + truth index + contradictions
guardrails.py GuardrailEngine (DPDP/GDPR gates + audit)
simulate.py stance / conflicts / appeal reasoning
ingest.py duet/html/web ingestion (consent + SSRF guard)
validate.py the 6-check neural validation harness
engine.py Celebrum facade
cli.py, gui.py, mcp.py, __main__.py
data/ demo export + matruswara sources (satyasandha, oi)
tests/ unittest suite (python -m unittest discover -s tests)
docs/ SRS + validation mappingEverything lives in one SQLite file at ~/.celebrum/ (override
CELEBRUM_HOME). Nothing leaves the device unless you ship a snapshot.
The personal tensor is feature-hashed and signed-randomized — no plaintext.
Every ingest requires explicit consent; every change is audit-logged (append-only). Right to erasure is wired in and non-reversible (it's a right).
ingest web refuses private-IP / loopback / link-local targets (SSRF guard).
CC BY 4.0 — Attribution 4.0 International.
You may share and adapt with attribution; see LICENSE.
Copyright (c) 2026 karun99 (saikarun085@gmail.com).
Approve/reject a pending or active guardrail by id (high tier requires approval).
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | openworker | |
| approve | No | ||
| guardrail_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the tool can approve or reject a guardrail but does not explain side effects, what happens to an active guardrail upon rejection, permissions required, or any confirmations or return values. This is thin for a mutating action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. The parenthetical about high-tier approval is relevant and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the sole source of context. It omits return behavior, side effects of rejection, the role of 'by', and what 'high tier' means, leaving the agent without enough to call the tool confidently in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It clarifies that guardrail_id is the identifier and that approve/reject relates to the approve boolean, but it leaves the 'by' parameter entirely unexplained and does not clarify the meaning of a false or missing approve value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('Approve/reject') and a clear resource ('guardrail by id'), scoped to 'pending or active' guardrails. This distinguishes it from siblings like propose_guardrail or validate, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'pending or active' and 'high tier requires approval' context implies when to use the tool, but there is no explicit guidance about when not to use it or which sibling tool should be chosen instead. Usage is conveyed indirectly rather than stated outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose persona guardrail adaptations tiered by risk (low/medium/high).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, yet it does not state whether proposing guardrail adaptations is read-only, persists anything, or returns a proposal artifact. The risk tiers are mentioned but their behavioral implications are left unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no repetition or filler, and the core action is front-loaded. It earns its place despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotation coverage, so the description alone must explain what happens when the tool is called. It says what is proposed but not what the caller receives or whether the proposal changes state, leaving the tool incompletely specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema coverage is 100%. Baseline for no-parameter tools is 4; the description has no parameter semantics to add, and none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Propose') and resource ('persona guardrail adaptations') and adds a distinctive risk-tiering dimension ('low/medium/high'). It is clear on its own, but it does not explicitly distinguish itself from sibling tools such as approve_guardrail, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like simulate or approve_guardrail. The verb 'Propose' hints at a pre-approval workflow, but the description never states conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recall memories (neurons) grounded in identity and evidence (ID-RAG + PGMem).
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query | Yes | ||
| identity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It hints at a mechanism ('ID-RAG + PGMem') but doesn't disclose whether the tool has side effects, what it returns, how the parameters alter behavior, or any required prior context. This is a significant gap for a memory-recall tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is structurally efficient. However, the inclusion of unexplained acronyms ('ID-RAG + PGMem') adds noise rather than clarity, so not every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and zero schema descriptions, the description is far too minimal. It doesn't explain what the recalled memories look like, how to interpret results, or how the parameters affect the output, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. It does not mention 'query', 'k', or 'identity', nor their roles or constraints. The agent receives no semantic information to correctly set these inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Recall') and resource ('memories (neurons)'), but the qualifications 'grounded in identity and evidence (ID-RAG + PGMem)' are cryptic and don't clearly differentiate it from siblings without domain knowledge. It's not a tautology, but it leaves ambiguity about what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like celebrum.simulate or celebrum.snapshot. It doesn't state what conditions call for recall or mention any exclusions, leaving the agent to guess based on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a 'what if' scenario through the Persona Model; returns stance, reasoning and value conflicts.
| Name | Required | Description | Default |
|---|---|---|---|
| scenario | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that the tool runs a simulation and returns outputs, but it does not mention side effects, state changes, permissions, or whether it is read-only. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the tool's purpose and output. It is concise with no wasted words, though it could have included a bit more structural guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, no output schema, and minimal parameter details, the description is too sparse. It states the return values but omits side effects, usage boundaries, and error conditions. For a simple one-parameter tool, it is not complete enough for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter details. It only refers to a 'what if' scenario, providing a minimal hint but no explanation of scenario format, constraints, or examples. The single 'scenario' parameter is not elaborated meaningfully beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and resource ('Persona Model') and states the output (stance, reasoning, value conflicts). It is clear but does not explicitly differentiate from sibling tools like celebrum.recall or celebrum.validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'what if scenario' implies when to use the tool, but there is no explicit guidance about when not to use it or how it compares to alternatives. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a snapshot of the whole brain (persona, memory, truth, guardrails, tensor).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral burden. 'Return a snapshot' strongly implies a read-only operation and the list of contents clarifies what the snapshot covers, but the description does not explicitly guarantee side-effect freedom or describe output format, freshness, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. The parenthetical list efficiently communicates the snapshot contents without overloading the main statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no output schema, no annotations), the description is mostly complete: it states the action and the returned components. It falls slightly short by not specifying the output shape or any usage caveats, but those are not critical for a no-argument snapshot call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics to document. The zero-parameter baseline applies, and the description adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a clearly defined resource ('snapshot of the whole brain') with an explicit enumeration of components (persona, memory, truth, guardrails, tensor). It is clear and distinct from the sibling operations (simulate, propose/approve_guardrail, validate), though it does not explicitly contrast itself with celebrum.recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intent to fetch a full-state snapshot is implied by 'Return a snapshot...', so an agent can infer when to call it, but the description gives no explicit when-to-use guidance nor mentions any alternative tools. There are no preconditions or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the neural validation harness (BRIDGE, ID-RAG, PGMem, PTM, DPDP, performance).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool runs the validation harness but does not say whether it is read-only, how long it runs, what output it produces, or whether it has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the main action, and the parenthetical list adds useful specificity without fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and no parameter structure, the description is the only information source. It explains what the tool runs but not what the result looks like, what each component validates, or when an agent should choose it over siblings. This leaves meaningful gaps for a tool with no other structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 and no parameter documentation is needed. The description adds no parameter detail, but none is required for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (the neural validation harness) and lists its component suites (BRIDGE, ID-RAG, etc.), making its purpose reasonably clear. It does not explicitly contrast with siblings, but 'validate' is semantically distinct from recall, simulate, and guardrail actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to run validation versus using sibling tools like simulate or recall. The description lists what the harness includes but offers no conditional logic, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0celebrum.approve_guardrailcelebrum.propose_guardrailcelebrum.recallcelebrum.simulatecelebrum.snapshotcelebrum.validateScored across 6 tools
Each tool targets a distinct operation: memory recall, scenario simulation, guardrail proposal/approval, brain snapshot, and validation. There is no meaningful overlap, even though recall and snapshot both touch memory—they serve clearly different purposes.
The tools mostly follow an imperative verb or verb_noun pattern with a consistent celebrum. prefix, and the guardrail pair is well-structured. Minor inconsistency exists because 'snapshot' is a noun used as a verb and bare verbs like recall/simulate/validate lack explicit objects.
Six tools is well-scoped for a focused persona/memory/guardrail server. Each tool earns its place, and the set is neither too thin nor bloated.
The surface covers retrieval, simulation, guardrail lifecycle, state inspection, and validation. There are minor gaps such as no explicit memory-write or persona-editing tool, but snapshot and validate reduce potential dead ends.
Governed personal world model and memory for your AI agent. Pair once, connect over MCP.
Private-by-default, local-first memory/context/task orchestrator for MCP apps and agents.
Person-owned AI memory that learns, not just stores — portable context for any MCP client.
NeuralBrain MCP Server - RAG, Vector Memory, LLM Routing, Agent Identity, x402 Payments
