Skip to main content
Glama

Gnosys — One Brain. Zero Context Bloat.

Gnosys gives AI agents persistent memory that survives across sessions, projects, and machines.

The central brain is a single SQLite database at ~/.gnosys/gnosys.db with sub-10ms reads — no vector DBs, no black boxes, no external services. Federated search ranks results across project, user, and global scopes. It runs as a CLI and as a full MCP server that drops straight into Claude Code, Claude Desktop (Chat / Cowork / Code), Cursor, Codex, Gemini CLI, Antigravity, Grok Build, or any MCP client. When you want a human-readable view, gnosys export regenerates a full Obsidian vault on demand.

Install

Requires Node.js ^22.16.0 || >=24.0.0. FTS5 requires this floor. Node 23.x is unsupported. SQLite uses built-in node:sqlite. No native SQLite dependency or rebuild is needed when switching supported Node versions.

npm install -g gnosys
gnosys setup          # configures provider, API key, and your IDE/agent

Optional local embeddings. Gnosys auto-installs @huggingface/transformers. If it cannot install, use an external embedding API. SQLite does not need this package.

Related MCP server: Mem0 MCP Server

Quick start

gnosys setup ides                                        # wire MCP into your IDEs (once)
cd your-project
gnosys init                                              # register the project
gnosys add "We chose PostgreSQL over MySQL for JSON support"
gnosys recall "database selection"                       # what's relevant right now

That's the 60-second tour. Everything else lives on gnosys.ai.

What you get

  • Central brain — one ~/.gnosys/gnosys.db unifies every project (project / user / global scopes). Sub-10ms reads, SQLite as the sole source of truth.

  • Federated search — tier-boosted hybrid (FTS5 keyword + semantic) search across scopes, with recency and reinforcement.

  • MCP server — gnosys serve exposes 50+ memory tools to any MCP client. Sandbox-first runtime keeps context cost near zero.

  • Web Knowledge Base — gnosys web build turns any site into a searchable index for serverless chatbots, with optional build-time vectors for serverless-safe hybrid semantic search. Zero runtime deps.

  • Dream Mode — idle-time consolidation: confidence decay, summaries, relationship discovery. Never deletes — only suggests.

  • Multi-machine sync — share your brain across machines; conflict detection with skip-and-flag resolution.

  • Obsidian export — gnosys export regenerates a full vault with frontmatter, [[wikilinks]], and graph data.

MCP Tool Reference

All tools are exposed over stdio and HTTP transports. Many tools accept an optional projectRoot parameter to target a specific project store.

This package installs two binaries:

  • gnosys — the CLI. gnosys serve starts the MCP server (stdio by default, --transport http for the central-server topology). gnosys setup ides wires gnosys-mcp into your IDE/agent configs.

  • gnosys-mcp — a direct alias for the MCP stdio server entry, installed with npm install -g gnosys, for MCP clients that spawn the server binary directly. Equivalent to gnosys serve. With npx, use npx -y gnosys serve.

On stdio EOF, the server drains received requests, writes their responses, and closes resources before exiting 0. Embedding flushes get at most 500 ms or one third of the shutdown timeout; reindex or an embedding-enabled Dream run recovers missing vectors. Cleanup errors or the 1500 ms shutdown backstop exit 1. GNOSYS_SHUTDOWN_TIMEOUT_MS accepts plain decimal integers without whitespace (100–60000 ms). Out-of-range integers and signed infinities warn and clamp to the nearest bound; other formats warn and use 1500 ms. Both transports exit 130 for SIGINT and 143 for SIGTERM. The first signal during an EOF drain lets requests finish and sets that exit status. Only a second actual signal forces immediate resource cleanup and exits with its status. HTTP ignores stdin closure. On a signal, HTTP rejects new requests and drains admitted POST responses before closing SSE streams. Synchronous event-loop blocking (for example a long handler or SQLite call) defeats the shutdown bound/backstop; there is no watchdog process.

Tool

Tier

Description

gnosys_discover

standard

Discover relevant memories by describing what you're working on.

gnosys_read

core

Read a specific memory.

gnosys_search

standard

Search memories by keyword across all stores.

gnosys_list

standard

List memories across all stores, optionally filtered by category, tag, or store layer.

gnosys_add_structured

core

Preferred for LLM agents. Add a memory with structured fields you supply (title, category, tags, content) — makes no server-side LLM call.

gnosys_add

full

Add a memory from raw text; the server's LLM structures it. For non-agent callers (scripts, cron) — agents should use gnosys_add_structured.

gnosys_tags

standard

List all tags in the registry, grouped by category.

gnosys_tags_add

full

Add a new tag to the registry.

gnosys_reinforce

core

Signal whether a memory was useful.

gnosys_init

core

Initialize Gnosys in a project directory.

gnosys_migrate

full

Migrate a Gnosys store (.gnosys/) from one directory to another.

gnosys_update

core

Update an existing memory's frontmatter and/or content.

gnosys_stale

full

Find memories that haven't been modified or reviewed within a given number of days.

gnosys_commit_context

full

Pre-compaction memory sweep.

gnosys_history

full

View audit history for a memory.

gnosys_lens

standard

Filtered view of memories.

gnosys_timeline

standard

View memory creation and modification activity over time.

gnosys_stats

standard

Summary statistics across all memories — totals by category, status, author, authority, average confidence, and date ranges.

gnosys_links

standard

Show wikilinks for a specific memory — outgoing [[links]] and backlinks from other memories.

gnosys_graph

standard

Show the full cross-reference graph across all memories.

gnosys_bootstrap

full

Batch-import existing documents from a directory into the memory store.

gnosys_import

full

Bulk import structured data (CSV, JSON, JSONL) into Gnosys memories.

gnosys_hybrid_search

core

Main search: keyword, semantic, or hybrid ranking with snippets and IDs.

gnosys_semantic_search

standard

Search memories using semantic similarity only (no keyword matching).

gnosys_reindex

full

Rebuild all semantic embeddings from every memory file.

gnosys_ask

standard

Ask a natural-language question and get a synthesized answer with citations from the entire vault.

gnosys_maintain

full

Run vault maintenance: detect duplicate memories, apply confidence decay, consolidate similar memories.

gnosys_dearchive

full

Force-dearchive memories from archive.db back to active.

gnosys_reindex_graph

full

Build or rebuild the wikilink graph (.gnosys/graph.json).

gnosys_dream

full

Run a Dream Mode cycle — idle-time consolidation that decays confidence, generates category summaries, discovers relationships, and creates review suggestions.

gnosys_export

full

Export gnosys.db to Obsidian-compatible vault — atomic Markdown files with YAML frontmatter, [[wikilinks]], category summaries, and relationship graph.

gnosys_dashboard

core

Show the Gnosys system dashboard: memory counts, maintenance health, graph stats, LLM provider status.

gnosys_stores

full

Debug tool — lists all detected Gnosys stores across registered projects, MCP workspace roots, cwd, and environment variables.

gnosys_recall

core

Fast memory recall — inject relevant memories as context.

gnosys_audit

full

View the audit trail of all memory operations (reads, writes, reinforcements, dearchives, maintenance).

gnosys_preference_set

core

Set a user preference.

gnosys_preference_get

core

Get a user preference by key, or list all preferences.

gnosys_preference_delete

standard

Delete a user preference by key.

gnosys_sync

full

Get the current user preferences + project conventions formatted as a GNOSYS:START/GNOSYS:END block.

gnosys_federated_search

standard

Search across scopes with boosts, memory IDs, status labels, and replacements before history.

gnosys_detect_ambiguity

full

Check if a query matches memories in multiple projects.

gnosys_briefing

core

Generate a project briefing — a summary of memory state, categories, recent activity, and top tags.

gnosys_portfolio

full

Portfolio dashboard — shows all registered projects with memory counts, categories, status snapshots, roadmap items, and recent activity.

gnosys_remote_status

full

Check the status of remote sync (multi-machine).

gnosys_remote_push

full

Push local memory changes to the remote (NAS) database.

gnosys_remote_pull

full

Pull remote memory changes to the local database.

gnosys_remote_resolve

full

Resolve a sync conflict by choosing which version to keep.

gnosys_update_status

standard

Get the prompt/template for writing a dashboard-compatible status memory for this project.

gnosys_working_set

standard

Get the implicit working set — recently modified memories for the current project.

gnosys_ingest_file

standard

Ingest a file (PDF, DOCX, TXT, MD, images via vision LLM, audio/video via Whisper transcription) into Gnosys memory.

gnosys_attach

standard

Attach a small binary file (logo, diagram, screenshot, small PDF) inline to a memory (~10MB limit; syncs machine-to-machine).

gnosys_get_attachment

standard

Retrieve the binary attachment stored on a memory (base64 bytes, or write to disk via outputPath).

gnosys_trace

standard

Trace a codebase directory and store procedural "how" memories with call-chain relationships.

gnosys_reflect

core

Record a real-world outcome against related memories, adjusting their confidence and linking them.

gnosys_traverse

core

Walk relationship chains from a memory id (BFS, depth-limited), optionally filtered by direction or relationship types.

gnosys_toolset

core

Inspect the tool catalog or switch the active tier.

Toolset tiers

Tool descriptions and schemas consume agent context, so since v6.2.0 every session starts on the core tier and agents self-escalate in-session: calling gnosys_toolset without arguments lists what the higher tiers add, and gnosys_toolset {"set": "standard"|"full"} enables them at runtime (and "core" shrinks back). The switch emits notifications/tools/list_changed, so MCP clients pick up the new tools automatically.

Tier

Tools

Contents

core (default)

14

Main memory workflow, hybrid search, reflection, traversal, and tier switching

standard

33

Core plus specialist search, tracing, browsing, attachments, and ingestion

full

56

All tools, including freeform ingestion, maintenance, remote sync, and export

GNOSYS_MCP_TOOLSET=core|standard|full overrides the starting tier (unknown values warn on stderr and fall back to core). The starting toolset and escalation hint are announced in the MCP server instructions. See docs/mcp-toolsets.md.

Documentation

Full docs & guides

https://gnosys.ai

Complete CLI + MCP reference

https://gnosys.ai/guide.html

Changelog

CHANGELOG.md

Contributing

CONTRIBUTING.md

Security policy

SECURITY.md

Report a bug / request a feature

GitHub Issues

License

MIT © Proticom. See LICENSE.

Available Tools

14 tools
gnosys_add_structuredA

Save a structured memory without an LLM call, returning its ID, store label, and up to three active overlaps. Supply title, category, tags, and Markdown content; store defaults to project, author to ai, authority to observed, and confidence to 0.8 (also used for an explicit zero). supersedes links comma-separated predecessor IDs; cross-scope or cross-project links require allowCrossScope=true. Use gnosys_update instead to change an existing memory or unlink a predecessor with superseded_by="".

Inputs: tags (required), title (required), content (required), category (required), +8 more.

gnosys_briefingA
Read-onlyIdempotent

Summarize a project as Markdown with memory counts, categories, activity from the last seven days, top tags, and a summary. projectId takes precedence over projectRoot; otherwise detect from projectRoot or cwd. all=true returns summaries for all projects and ignores both selectors (default false). Use gnosys_dashboard instead for system health, graph statistics, and provider status as JSON.

Inputs: all, projectId, projectRoot.

gnosys_dashboardA
Read-onlyIdempotent

Inspect local memory-system health as JSON with memory counts, maintenance health, graph statistics, and LLM provider status. projectRoot selects the project context; omission uses the detected context. Use gnosys_briefing instead for a project summary and recent activity as Markdown.

Inputs: projectRoot.

gnosys_initA
Destructive

Initialize a project directory, returning its identity, store path, and setup summary. Pass an absolute directory (e.g. /work/app); projectName defaults to its basename. Creates .gnosys/ metadata and registers the project in the central SQLite store; run this before project-scoped operations on a new root. Use gnosys_briefing instead to inspect an already registered project.

Inputs: directory (required), projectName, projectRoot.

gnosys_preference_getA
Read-onlyIdempotent

Read a user preference by key, returning its title, value, confidence, and modified date, or omit key to list all preferences with their keys and values. Keys are kebab-case, e.g. {"key":"code-style"}; missing keys return a not-found message. Use gnosys_preference_set instead to save or replace a preference.

Inputs: key, projectRoot.

gnosys_preference_setA
Destructive

Save or replace a user preference across projects, returning its key, title, and value. Use kebab-case keys, e.g. {"key":"code-style","value":"Use named exports"}; title is generated from the key if omitted. Preferences persist as user-scoped memories; the CLI command gnosys sync refreshes generated rules files. Use gnosys_preference_get instead to inspect a key or list preferences.

Inputs: key (required), value (required), tags, title, +1 more.

gnosys_readA
Read-onlyIdempotent

Read a memory by ID (e.g. arch-012) or layer-prefixed path (e.g. project:decisions/why-not-rag.md), returning Markdown content, metadata, and supersession links. Unprefixed paths search stores in precedence order. Use gnosys_hybrid_search instead when you do not know the ID, or gnosys_recall for several relevant memories as context.

Inputs: path (required), projectRoot.

gnosys_recallA
Read-onlyIdempotent

Recall relevant memories as a context block for a task, e.g. query="JWT middleware". query="*" selects by reinforcement, confidence, and recency; limit uses config by default and is capped at 15; aggressive defaults to config (true). Use gnosys_hybrid_search instead to inspect ranked results or gnosys_read for one complete body. Registered projectRoot includes project, user, and global memories; omit it for all projects, or run gnosys_init for an unregistered root. Installed hooks may already inject this context per prompt.

Inputs: query (required), limit, traceId, aggressive, +1 more.

gnosys_reflectA

Record an outcome as a new reflection memory, returning its ID, confidence delta, updated memory IDs and confidences, and relationship count. memoryIds defaults to up to five keyword matches on outcome; success defaults to true and confidenceDelta to +0.05 on success or -0.1 on failure, clamping resulting confidence to 0.05..1. Success also reinforces targets and adds validates links; failure adds contradicts links. Use gnosys_reinforce instead for usefulness feedback without creating an outcome memory; each reflection call creates a new record and applies the delta again.

Inputs: outcome (required), notes, success, memoryIds, +2 more.

gnosys_reinforceA

Record usefulness feedback for one memory, returning a signal confirmation. useful increments reinforcement and resets decay; not_relevant records a routing miss without changing the memory; outdated marks it for review. Use gnosys_reflect instead to record an outcome memory, link evidence, and adjust confidence; repeated useful calls reinforce again.

Inputs: signal (required), memory_id (required), context, projectRoot.

gnosys_toolsetA
Idempotent

List the active tool tier and a catalog of higher-tier tools as text, or set core, standard, or full to switch tiers and return added/removed tool names. Starts on core unless configured otherwise; omit set to inspect without switching. Example: {"set":"standard"} enables specialist search and tracing tools for this session.

Inputs: set.

gnosys_traverseA
Read-onlyIdempotent

Traverse stored memory relationships breadth-first, returning an indented text tree of IDs, titles, confidences, depths, and connecting edges. direction is out, in, or both (default); depth defaults to 3 with range 1..10. relTypes accepts stored relationship strings, including references, supersedes, leads_to, follows_from, requires, validates, contradicts, and corroborates; omission follows all types. Example: {"memoryId":"arch-012","depth":2,"relTypes":["requires"]}. To create relationships from source code, use gnosys_trace instead, which requires gnosys_toolset {"set":"standard"}.

Inputs: memoryId (required), depth, relTypes, direction, +1 more.

gnosys_updateA
Destructive

Update an existing memory by ID or path, returning a confirmation and changed fields. To archive, retire, or "delete" a memory, set status to archived or superseded with superseded_by (the replacement ID, mapped to supersededBy / --superseded-by in the CLI); hard deletion is human-only by design via the CLI. confidence accepts 0..1; content replaces the Markdown body; supersedes adds predecessor links and superseded_by="" unlinks a predecessor. Links reject cycles and require allowCrossScope=true across scopes or projects. Use gnosys_add_structured instead for a new memory.

Inputs: path (required), tags, title, status, +7 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.3/5.0

    Scored across 14 tools

    Disambiguation4/5

    Most tools have clearly distinct purposes, and descriptions explicitly cross-reference alternatives (read vs hybrid_search vs recall; reinforce vs reflect; dashboard vs briefing; update vs add_structured). The memory-retrieval trio (read/recall/hybrid_search) and the feedback pair (reinforce/reflect) overlap somewhat, but the guidance is strong enough that an agent can select confidently.

    Naming Consistency4/5

    All tools share the gnosys_ prefix and use snake_case verb_noun patterns (read, add_structured, update, hybrid_search, preference_set/get, traverse). Minor deviations like gnosys_init and gnosys_toolset are noun-style rather than verb_noun, but overall very predictable.

    Tool Count5/5

    14 tools is well within the ideal range, each mapping to a distinct memory-system operation (read/write/search/feedback/admin/preferences). The tiering mechanism gates advanced tools without bloating the default surface.

    Completeness4/5

    The surface covers the full memory lifecycle: create (add_structured), read, update/archive, search (hybrid_search/recall/traverse), feedback (reinforce/reflect), project setup (init/briefing/dashboard), and preferences. Hard deletion is intentionally human-only via CLI, a deliberate rather than accidental gap.

    Maintenance

    ActivityMaintained
    ResponsivenessLimited data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      D
      maintenance
      With Memori's MCP server, your agent can retrieve relevant memories before answering and store durable facts after responding, keeping context across sessions without any SDK integration. With MCP, it can: Store stable user facts and preferences after answering using the advanced_augmentation tool Recall relevant memories before answering using the recall tool Maintain context across sessions us
      2
      48 npm
      2
      MIT