Jarvis Orb is a persistent memory MCP server that gives AI tools long-term memory across sessions, with a desktop orb that visualizes thought processes in real time.
Memory Management
Save memories — Store information across 4 tiers (episodic, semantic, project, procedural) with optional tags, source, and project context
Search memories — Full-text search (FTS5) with temporal scoring that prioritizes recent memories using a 30-day half-life decay, plus contradiction filtering
Verify/manage memories — Mark memories as verified, superseded (replacing old with new), or contradicted (flagging conflicts), keeping the knowledge base accurate
Entity Tracking
Create entities — Track structured objects (people, projects, decisions, tools) with an initial state
Update entity state — Modify state while automatically recording the full transition history with an optional reason
Query entities — Look up entities by type, name, or both to retrieve current state and history
Relate entities — Define subject–predicate–object relationships between entities to build a lightweight knowledge graph
Integration & Visualization
Works with MCP-compatible tools like Claude Code, Cursor, and Windsurf
Desktop orb visualizes real-time brain activity in response to memory operations, searches, contradictions, and entity changes
Maintains persistent context across sessions, eliminating the need to re-explain decisions, preferences, and project context
Actual footage. Not a mockup.
It remembers your decisions. It tracks your world. It glows on your desktop, alive.
Website · Download · Report Bug
English | 한국어
Every session, your AI starts over. Your decisions, your preferences, your project context — gone. You explain yourself again. And again. And again.
"We decided to use SQLite." → Three days later, it suggests PostgreSQL.
"This PR was merged yesterday." → It doesn't know. It never remembers state.
"What was the architecture decision?" → Gone. The session ended.
Related MCP server: memora
Jarvis Orb gives your AI a persistent brain and shows its thought process as a living orb on your desktop.
Without Jarvis Orb | With Jarvis Orb | |
Context | Every session starts from zero | Carries over automatically |
Decisions | Reversed decisions come back | Contradictions detected and filtered |
State | "What's the status?" → guess | Exact state + transition history |
Visibility | No idea what it's thinking | Every thought, live on your screen |
macOS (Apple Silicon) / Linux:
curl -fsSL https://raw.githubusercontent.com/thestack-ai/jarvis-orb/main/install.sh | bashRequires Apple Silicon (M1/M2/M3/M4). Use the terminal command above for the smoothest install experience.
Windows (PowerShell):
irm https://raw.githubusercontent.com/thestack-ai/jarvis-orb/main/install.ps1 | iexThat's it. Brain starts. Orb floats. Claude Code connects.
Verify your install:
jarvis-orb --doctorPlatform | Brain (MCP) | Orb (Desktop) |
macOS Apple Silicon (M1+) | Yes | Yes |
macOS Intel | Yes | Yes |
Windows x64 | Yes | Yes |
Linux | Yes | Not yet |
Add to your MCP config (~/.cursor/mcp.json or equivalent):
{
"mcpServers": {
"jarvis-brain": {
"command": "python3",
"args": ["-m", "jarvis_brain.mcp_server"],
"env": {
"PYTHONPATH": "~/.jarvis-orb/lib:~/.jarvis-orb"
}
}
}
}# Remove Brain + data
rm -rf ~/.jarvis-orb
# Remove from Claude Code
claude mcp remove jarvis-brain
# Remove Orb app (macOS)
rm -rf "/Applications/Jarvis Orb.app"
# Remove PATH entry from ~/.zshrc or ~/.bashrc
# Delete the line: export PATH="$HOME/.jarvis-orb/bin:$PATH"Watch it think.
# | Feature | Description |
01 | 4-Tier Memory | Episodic, semantic, project, procedural — auto-classified and ranked by recency |
02 | Temporal Scoring | 30-day half-life decay. Recent memories surface first. Old context fades naturally |
03 | Contradiction Detection | Conflicting memories flagged. Superseded decisions marked stale. Only truth surfaces |
04 | Entity Tracking | Projects, PRs, decisions tracked as objects with full state transition history |
05 | Relationship Storage | People → projects → decisions connected as a lightweight knowledge graph |
06 | FTS5 Search | Full-text search across all memories with observation filtering |
memory_save Save a memory (auto-classified into 4 tiers)
memory_search Search with temporal scoring + contradiction filtering
memory_verify Mark memories as verified, superseded, or contradicted
entity_create Track a project, person, decision, or tool
entity_update Update entity state (records transition history)
entity_query Query entities by type or name
entity_relate Create relationships between entitiesWorks with Claude Code, Cursor, and any MCP-compatible tool.
Every thought, visible.
The orb is not decorative. It shows you what the brain is doing, in real time.
Brain Event | Orb Response |
Memory saved | Particles absorb into orb |
Contradiction detected | Red/orange pulse wave |
Entity state changed | Cyan flash + scale pulse |
Search executed | Violet color shift |
Context compressed | Shrink, brighten, expand |
Team dispatched | Orb splits into sub-orbs |
3MB desktop app. Always-on-top. Draggable. Click to see logs.
Monday morning standup — "What did we work on last week?" Brain searches episodic memories with temporal scoring. Returns a ranked summary. No digging through chat history.
Mid-project contradiction — "We should use Redis for caching." Brain detects this contradicts a previous decision. Flags the conflict. The orb pulses red. You see it happening.
New session, no context loss — "Continue where we left off." Brain loads project state, recent decisions, and your preferences. No re-explaining.
Claude Code / Cursor
↕ MCP (stdio)
Brain Lite — Python · aiosqlite · FTS5 · ~/.jarvis-orb/brain.db
↕ WebSocket
Orb — Tauri · Three.js · WebGL · 3MB · Always-on-top3MB | App size. Not 150MB. |
7 | MCP tools. Memory, entities, search. |
0 | Cloud dependencies. Everything local. |
Jarvis Orb was extracted from a working AI control plane — Jarvis — running 19 modules, a knowledge graph with 100+ entities, 500+ memories, and 22 agent teams. This is the lightweight, open-source version of that brain.
"I built a personal AI operating system. After months of using it, I realized the core — the brain and the visualization — should be available to everyone."
Orb Customization — Custom orb skins, color themes, animation profiles
Brain Pro — Advanced memory with full knowledge graph, multi-model routing, autonomous reasoning loop
Auto-update — Seamless in-app updates
Plugin System — Extend Brain with custom MCP tools
PRs welcome. See CONTRIBUTING.md.
git clone https://github.com/thestack-ai/jarvis-orb.git
cd jarvis-orb
# Brain
cd brain && uv venv .venv && source .venv/bin/activate
uv pip install aiosqlite websockets mcp pytest pytest-asyncio
python -m pytest tests/ -v
# Orb
cd ../orb && pnpm install && pnpm tauri devMIT
Your AI will start remembering.
Create an entity (person, project, decision, tool, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| state | No | {} | |
| entity_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose side effects, permissions, duplicate handling, or return behavior. Minimal behavioral transparency.
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, efficiently states purpose. No wasted words, but could benefit from additional structured details 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?
With 3 parameters, no annotations, and output schema present but not described, the description is too sparse to fully inform an agent. Missing critical usage details.
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 coverage is 0%; description only hints at entity_type via examples and mentions name, but completely ignores the 'state' parameter. Not sufficient to compensate for lacking schema descriptions.
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?
Description clearly states 'Create an entity' with verb and resource, and provides examples of entity types (person, project, decision, tool), distinguishing from sibling tools like entity_query and entity_update.
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?
No guidance on when to use this tool vs alternatives such as memory_save or entity_relate. The description lacks context for when creation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query entities by type and/or name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| entity_type | No |
| Name | Required | Description |
|---|---|---|
| result | 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 disclosing behavioral traits. However, it only states the basic query functionality without any mention of read-only nature, destructive potential, authentication requirements, rate limits, or whether it modifies state. This is insufficient for an agent to understand side effects or constraints.
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 extremely concise, consisting of a single sentence that immediately conveys the tool's purpose. Every word serves a function, with no redundancy or filler. It is front-loaded and efficient.
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 simplicity (2 optional parameters, output schema present), the description is adequate in telling what it does, but it lacks additional context such as the nature of entities, example queries, or the structure of the output (though output schema covers that). It leaves the agent with basic understanding but no deeper behavioral or usage nuance.
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?
With 0% schema description coverage, the description adds meaning by indicating that both parameters ('name' and 'entity_type') are optional filters for querying. However, it does not specify the expected format, default behavior when both are empty, or any relationship between the parameters, which would help the agent construct proper queries.
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 'Query entities by type and/or name' clearly states the action (query), the resource (entities), and the filtering criteria (type and/or name). It effectively distinguishes from sibling tools like entity_create, entity_relate, and entity_update, which involve creation, relation, and update operations respectively, and from memory_* tools that handle unstructured data.
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 description provides no guidance on when to use this tool vs alternatives such as memory_search or memory_verify. It does not specify that this tool is for structured entities while memory tools handle unstructured data, nor does it mention any prerequisites or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a relationship between two entities.
| Name | Required | Description | Default |
|---|---|---|---|
| object_id | Yes | ||
| predicate | Yes | ||
| subject_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It fails to disclose behavioral traits such as whether relationships can be overwritten, permissions needed, or handling of non-existent entities. The output schema exists but content is unknown.
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 too sparse (one sentence) and lacks important information. While concise, it sacrifices completeness.
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 3 required parameters, no annotations, and an output schema with unknown content, the description is incomplete. It does not explain return values, side effects, or edge 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?
The schema has 0% description coverage for parameters, and the tool description adds no meaning to 'subject_id', 'predicate', or 'object_id'. The agent gets no help understanding what valid predicates are or expected ID formats.
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 clearly states the action (create) and resource (relationship between two entities). It distinguishes from siblings like entity_create (which creates entities) and memory_save (saves contexts). However, it could be more specific about the nature of the relationship.
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?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, conditions for use, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update entity state. Records transition history.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| entity_id | Yes | ||
| new_state | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, permissions, or idempotency. It only mentions recording transition history, lacking details on mutation behavior or constraints.
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 concise with two sentences, but it lacks front-loaded clarity about the tool's core purpose versus the transition history aspect.
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 presence of an output schema and three parameters, the description is insufficient—it does not explain return values, error conditions, or valid state transitions, limiting the agent's ability to use the tool correctly.
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 schema has 0% description coverage, and the tool's description adds no explanation for the three parameters (entity_id, new_state, reason), leaving the agent to infer their meaning from names alone.
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 clearly states the tool's action ('Update entity state') and an additional behavior ('Records transition history'), distinguishing it from siblings like entity_create and entity_query.
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 description provides no guidance on when to use this tool versus alternatives (e.g., entity_create or memory_save), nor does it specify conditions for use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a memory to the brain. Types: episodic, semantic, project, procedural.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| source | No | ||
| content | Yes | ||
| project | No | ||
| memory_type | No | episodic |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only says 'Save a memory' without disclosing side effects, idempotency, or authentication requirements. Listing types adds minimal behavioral context.
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 very short (one sentence plus a list), but it could be more structured. It front-loads the main action, but lacks organization for the types list.
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 5 parameters (1 required) and no annotations, the description is too sparse. It does not explain memory types, their usage, or the return value (despite an output schema). Key contextual information is missing.
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 should compensate. It only hints at the 'memory_type' parameter by listing types, but ignores 'tags', 'source', 'project', and 'content'. No parameter explanations are added beyond the raw schema.
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?
Description clearly states the action 'Save a memory' and specifies the resource ('to the brain'). It lists four memory types, making the purpose specific and distinct from sibling tools like memory_search or memory_verify.
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?
No guidance on when to use this tool versus alternatives such as entity_create or memory_search. No mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search memories with temporal scoring + observation filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to detail behavioral traits such as idempotency, side effects, or required permissions. The mention of 'temporal scoring' and 'observation filtering' hints at internal logic but does not disclose observable behavior for the agent.
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 concise, consisting of a single sentence, but it sacrifices necessary detail. It is appropriately sized for a simple tool but lacks structure or front-loading of critical information.
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?
Despite having an output schema, the description omits details about return values, pagination, or ordering. Given the complexity hinted by 'temporal scoring,' the description is insufficient for complete understanding.
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 description adds no meaning beyond the input schema, which has 0% coverage. It does not explain how the 'query' parameter should be formulated or how 'limit' affects results, leaving the agent to guess.
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 clearly states the tool searches memories with temporal scoring and observation filtering, distinguishing it from sibling tools like memory_save and memory_verify. However, it does not elaborate on what temporal scoring entails, leaving some ambiguity.
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?
No guidance is provided on when to use this tool versus alternatives like entity_query or memory_save. The absence of usage context or exclusions makes it hard for an AI to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify, supersede, or contradict a memory. Actions: verify, supersede (old:new), contradict (a:b).
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | verify | |
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions actions cryptically ('old:new', 'a:b') without explaining side effects, reversibility, or required permissions. Lacks clarity on what happens when a memory is verified, superseded, or contradicted.
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?
Two sentences, no fluff. Could be slightly more structured (e.g., list actions), but overall efficient.
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?
Despite being a multi-action tool with 2 parameters and an output schema, the description fails to explain return values, error conditions, or prerequisites. Omissions leave an agent uncertain about invocation behavior.
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 has 0% description coverage. Description adds meaning for 'action' parameter by listing valid actions and formats, but 'memory_id' is left unexplained. Partial compensation for low schema coverage.
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?
Description clearly states three distinct actions (verify, supersede, contradict) on a memory, differentiating it from sibling tools like memory_save or entity_update which have different purposes.
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?
No guidance on when to use each action or when to prefer this tool over alternatives like memory_search or entity_update. Missing explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: entity tools cover CRUD-like actions and relating, while memory tools handle saving, searching, and verifying. There is no functional overlap, ensuring an agent can easily distinguish them.
All tools follow a consistent snake_case verb_noun pattern (e.g., entity_create, memory_save). The naming is uniform and predictable, making it easy to infer tool purpose from the name.
With 7 tools covering two domains (entities and memories), the count is well-scoped. Each tool serves a necessary function, and the number is neither overwhelming nor insufficient for the apparent scope.
The tool set covers core operations for entities (create, read, update, relate) and memories (save, search, verify with supersede/contradict). Only deletion is missing, which is a minor gap but does not severely hinder core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A self-improving memory layer. Your memory, notes, tasks and goals, remembered everywhere.
Persistent AI memory with semantic search, conflict detection, and ticketing.
Persistent memory for AI agents. EU-hosted, privacy-first, hybrid recall, contradiction detection.
AI memory layer — one shared, persistent memory across every AI tool you connect.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheStack-ai/jarvis-orb'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
