Skip to main content
Glama
Sidarau

zme-mcp

by Sidarau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

zme-mcp

Zeug Memory Engine as an MCP server. Hybrid retrieval (vector + lexical, RRF-fused) and a bitemporal knowledge graph over Zeug's collected knowledge — 15k+ chunks of research, notes, articles and transcripts — exposed to any MCP client: Claude, Cursor, Codex, Hermes, and ChatGPT (deep research + company knowledge compatible).

Measured on the Zeug corpus: hybrid R@5 0.800 · MRR 0.562 · source-recall@10 0.900 — +18.1% MRR over vector-only.

Tools

Tool

What it does

Write?

search

One query string → {results: [{id, title, url}]}. ChatGPT deep-research compatible.

no

fetch

id (from search) → full chunk text + citation URL. ChatGPT compatible.

no

recall

Zeug's own notes/analysis/research only — "why did we decide X"

no

why

Causal chain between two knowledge-graph entities

no

near

Facts around one entity, with evidence quotes

no

remember

Record a durable note (pitfall, decision, incident). The only write path — backed by a SECURITY DEFINER function that can only create notes.

creates one note

Related MCP server: LLM Second Brain

Authentication — the zeuglab → ClawPanel auth model (alpha)

This server is the alpha ring of the ecosystem auth design:

Ring

Where

Auth

alpha

zeuglab ecosystem (this server)

OAuth 2.1 + optional legacy token

beta

ClawPanel

OAuth only; stores move from memory to Postgres

prod

ClawPanel multi-tenant

OAuth + per-profile labels, RLS-backed

OAuth 2.1, self-contained (no external IdP): DCR, PKCE, authorization codes, refresh tokens, revocation — the full flow ChatGPT performs. /authorize shows a zeuglab login form; profiles are configured server-side:

ZME_AUTH=oauth
ZME_BASE_URL=https://zme-mcp.fly.dev
ZME_OAUTH_PROFILES='{"alex":{"secret":"…","level":"owner"},
                     "guest":{"secret":"…","level":"viewer"}}'

Profile levels → scopes: owner/operator get zme:read + zme:write; viewer gets zme:read. The server forces scopes from the profile — client requests are never trusted. A viewer's tools/list doesn't even contain remember. In beta the in-memory stores become tables and passphrases become Supabase sessions; the scope contract stays identical, so alpha clients keep working.

Legacy token mode (ZME_AUTH=token + ZME_MCP_TOKEN) still works in the alpha ring for stdio-style clients that can't do OAuth; it is a startup error from ring beta onwards.

Configuration

Variable

Required

Purpose

ZME_SUPABASE_KEY

yes

Supabase key for the ZME project. The anon key is enough (SELECT-only + zme_remember). Never deploy a service-role key on a shared machine.

ZME_SUPABASE_URL

no

Defaults to Zeug's own memory project. Point at another ZME deployment (e.g. a ClawPanel tenant DB) to serve that instead.

NVIDIA_API_KEY

no

Enables the vector arm of hybrid search. Without it, everything still works in lexical mode (which is the arm that catches exact identifiers).

ZME_AUTH

no

oauth (default when profiles are set) or token (alpha ring only).

ZME_OAUTH_PROFILES

oauth

JSON map of profile name → {secret, level}.

ZME_BASE_URL

oauth

Public URL of the server (for OAuth metadata + redirects).

ZME_RING

no

alpha (default) / beta / prod — release channel gates.

ZME_MCP_TOKEN

token mode

Shared bearer for the HTTP endpoint.

On macOS, keys are also auto-resolved from the NoxKey keychain (one Touch ID prompt per session) when the env vars are absent.

Install & run — local agents (stdio)

No install needed with uv (any machine with Python):

uvx --from git+https://github.com/Sidarau/zme-mcp zme-mcp

or pipx: pipx install git+https://github.com/Sidarau/zme-mcp · PyPI (uvx zme-mcp) once the package is published there.

Claude Code — claude mcp add zme -- uvx --from git+https://github.com/Sidarau/zme-mcp zme-mcp

Claude Desktop / Cursor (mcpServers JSON):

{
  "zme": {
    "command": "uvx",
    "args": ["--from", "git+https://github.com/Sidarau/zme-mcp", "zme-mcp"],
    "env": { "ZME_SUPABASE_KEY": "…", "NVIDIA_API_KEY": "…" }
  }
}

Run as a service (HTTP) — for ChatGPT

zme-mcp --http --host 0.0.0.0 --port 8000
# streamable HTTP endpoint: POST /mcp · health: GET /healthz

Connect from ChatGPT (OAuth)

  1. Server is live at https://zme-mcp.fly.dev (this repo ships Dockerfile + fly.toml: flyctl deploy).

  2. In ChatGPT: Settings → Security and login → Developer mode → on.

  3. Go to chatgpt.com/plugins → + → enter https://zme-mcp.fly.dev/mcp.

  4. ChatGPT discovers the OAuth metadata, registers itself via DCR, and opens the zeuglab login form — sign in with your profile (alex + passphrase). The token it gets back carries your level's scopes.

  5. Use it in chat — and in deep research, where the search/fetch pair makes ZME a citable knowledge source.

Security model

  • Read path is plain SELECT through PostgREST with whatever key you configure — use the anon key anywhere shared.

  • The only write is remember, which calls zme_remember(): a SECURITY DEFINER function whose entire capability is "create one note". No UPDATE, no DELETE, no schema access.

  • The HTTP layer never logs keys; the token is compared, not echoed.

Client workspaces (ZEUG-795)

Each cmd.zeuglab.com project can get its own memory on omarchy ZME, separate from Zeug's memory and from every other client. The MCP endpoint that serves them is ZEUG-796; this is the database layer and an admin CLI.

Layout. Project ecis lives in schema ws_ecis (hyphens become underscores) with sources and chunks tables, the same hybrid search as ZME (HNSW cosine + RUM lexical, fused with RRF), and two roles: zme_ws_ecis_read and zme_ws_ecis_write (add-only: no update, no delete). Control functions live in schema zme_ws, which PostgREST does not expose.

Two locks.

  1. Privileges. Only a workspace's own roles can use its schema. No workspace role holds any privilege on Zeug's memory in public, on pg_net, or on another workspace.

  2. Row-level security, forced, keyed to the workspace the session declares (zme.workspace). A wrongly granted role still sees no rows unless the session also declares that workspace.

Services do not log in as workspace roles. cmd (and, later, the MCP server in ZEUG-796) call the narrow API in migrations/003_cmd_gateway.sql: one call names one workspace and one level, and the database keeps it inside that workspace. zme_ws_gateway is reserved and holds no memberships. The CLI and Workspaces in src/zme_mcp/workspace.py connect as postgres for administration: per call they switch to one workspace role (set local role) and declare that workspace (set_config('zme.workspace', …, true)).

Trust boundary. cmd is the authority on who is on which project. A leaked cmd key or a compromised cmd reaches client workspaces at the levels cmd could use, never Zeug's memory.

Setup and checks (as postgres unless noted):

psql "$ZME_DB" -f migrations/001_workspaces.sql            # idempotent; re-run after changing provision()
psql "$ZME_DB_SUPERUSER" -f migrations/002_net_hardening.sql  # once, as supabase_admin
psql "$ZME_DB" -f migrations/003_cmd_gateway.sql           # cmd gateway (zme_ws_caller); idempotent
psql "$ZME_DB" -X -v ON_ERROR_STOP=1 -f tests/workspace_isolation.sql   # 59 checks, rolls back; exits non-zero on any failure

CLI (ZME_WS_DSN is a libpq string; the password is injected per call):

export ZME_WS_DSN="host=100.118.214.24 port=54322 dbname=postgres user=postgres sslmode=disable"
zk() { ~/.local/bin/zeug-key run PGPASSWORD=zeuglab/zme/DB_PASSWORD -- python3 scripts/zme_ws.py "$@"; }
zk create ecis --title "ECIS"
zk add ecis --file kickoff.md --as alex@zeuglab.com
zk search ecis "who owns the Xactimate export"
zk copy ecis <zeug-source-id>          # owner copies one Zeug source in, vectors included
zk drop ecis --confirm ecis            # deletes the workspace and everything in it

Notes are chunked and embedded on write (ollama snowflake-arctic-embed:335m, the arctic-l space Zeug's memory uses), so they are searchable as soon as add returns. Without an embedding service, notes are stored without vectors and search uses the lexical arm.

cmd.zeuglab.com reaches workspaces through the public ZME front door (PostgREST) with one JWT for role zme_ws_caller (migrations/003_cmd_gateway.sql, Zeug Keys zeuglab/zeug-cmd/ZME_WS_JWT, minted with the PostgREST secret, valid a year). That role can execute public.zme_ws_call (status, search, sources, fetch, add) and public.zme_ws_setup and nothing else; cmd passes the project, the access level and the person's email. Notes added from cmd have no vectors until zme_ws.py embed-pending runs on the tailnet; until then they are found by the lexical arm.

Every role can read the catalog (table names, function bodies), so never put a secret in a function body.

Sharing from Zeug's memory (explicit only). Zeug's memory is internal by default; nothing reaches a client workspace unless someone runs share for named sources and a named project:

zk share ecis <zeug-source-id> ... --as alex@zeuglab.com   # dry run: flags per source, nothing written
zk share ecis <ids> --redact ID --accept ID2 --preview --as alex@zeuglab.com   # every outgoing field + a digest per source
zk share ecis <ids> --redact ID --accept ID2 --publish --approve ID=<digest> ID2=<digest> [--mask WORD ...] [--title ID=New title] --as alex@zeuglab.com
zk shares ecis                                             # audit: what was shared, how, by whom

Each source is read once into a snapshot; that snapshot is what is scanned (title, text, and every chunk's content, prefix and heading) and what is published, in one transaction with its audit row. A source already shared into the workspace is skipped. The scan (src/zme_mcp/share.py, regression cases in tests/test_share.py) flags other clients' names, negotiating positions, ownership and Zeug-finance talk, assessments of people, personal data, secrets and access codes, contact details and local paths. A run that asked to publish exits non-zero if any named source was refused or held. Nothing publishes on a clean scan: each source must be named in --accept (copied as is, vectors included) or --redact, and approved with the digest its preview printed. A payload that changed after its preview is refused. Redacting replaces spans with a known extent (tokens, emails, phone numbers, paths, masked literals, parenthesised access codes) in place and drops every other flagged line, including credential assignments, then re-chunks and re-embeds. A flagged title needs --title. URLs cross only as plain http(s) without credentials, query or fragment. Every publish is recorded in zme_ws.shares. --preview prints every outgoing field: URL, type, title, text, and each chunk's heading, prefix and content. The scan is a tripwire, not a judge: read what you publish.

Development

Quick project references

Owner tooling: scripts/zme-project sync, scripts/zme-project alias oc opencollective, then scripts/zme-project ref @oc or scripts/zme-project search @oc 'question'. New collaborator notes use a local draft, full preview and explicit digest approval before publishing. See the project memory workflow for setup, limits and collaborator connections.

Offline checks: python3 -m unittest discover -s tests -p 'test_project*.py' and python3 tests/test_share.py.

python3 -m venv .venv && .venv/bin/pip install -e .
printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"x","version":"0"}}}' | .venv/bin/zme-mcp

Available Tools

6 tools
fetchA
Read-onlyIdempotent

Fetch the full content of one search result by its id (a chunk UUID returned by search).

NameRequiredDescriptionDefault
idYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the useful context that the id is a chunk UUID from search and that full content is returned, but it does not disclose other traits like error behavior or pagination. This is adequate given the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It efficiently conveys the action, target, and key parameter context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only one parameter, an output schema, and strong annotations, the description covers the essential workflow (post-search retrieval by id). It could mention edge cases or prerequisites, but the simplicity and structured data make it reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It does by explaining that the 'id' parameter is a chunk UUID returned by search, giving semantic meaning beyond the schema's bare 'string' type. This is sufficient for a single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Fetch') and identifies the exact resource ('full content of one search result') and the id's origin ('chunk UUID returned by search'). This clearly differentiates it from sibling tools like search and recall.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'returned by search' implies the intended workflow: perform a search first, then use fetch with a result id. This provides clear context, though it does not explicitly state when *not* to use the tool or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

nearB
Read-onlyIdempotent

Facts around one entity in the knowledge graph, with evidence quotes.

NameRequiredDescriptionDefault
hopsNo
entityYes

Output Schema

NameRequiredDescription
resultYes

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only and idempotent behavior. The description adds the useful detail that evidence quotes are included, but does not explain how the 'hops' parameter affects traversal or mention any other behavioral caveats. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The one-sentence description is extremely concise and front-loaded, containing no fluff. While it sacrifices detail, it is perfectly sized for a simple tool description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the output schema, the description is incomplete: it omits the meaning of 'hops', provides no context for when to use the tool, and does not clarify its relationship to sibling tools. A brief usage example or parameter explanation would make it more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It implies 'entity' is the target entity, but 'hops' is entirely unexplained. This is a significant gap for a knowledge graph traversal tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly indicates the tool returns facts about a single entity, with evidence quotes. It identifies the resource (knowledge graph) and scope (one entity), but uses no explicit verb and does not explicitly differentiate from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus search, fetch, recall, why, or remember. The description only says what it does, leaving the agent to infer its place among alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recallA
Read-onlyIdempotent

Recall what Zeug itself wrote down — notes, analysis, compiled research. Use this (not search) for 'why did we decide X' questions. Set wide=true to also include articles and social posts.

NameRequiredDescriptionDefault
kNo
wideNo
queryYes

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, non-destructive, and idempotent behavior, so the description need not repeat that. It adds valuable context about content scope (notes, analysis, compiled research, and wider articles/social posts with wide=true). It doesn't detail return format, but an output schema exists, so that is covered elsewhere.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences deliver purpose, usage context, and parameter guidance without any fluff. The description is front-loaded and each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple retrieval tool with annotations and an output schema, the description covers the primary use case and content scope. However, it omits the 'k' parameter and does not mention alternative siblings other than 'search', leaving some ambiguity for distinguishing from tools like 'remember' or 'why'. Overall adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the burden of explaining parameters. It only explains 'wide' (broaden to articles/social posts), but does not describe 'query' or 'k'. The meaning of 'query' is implicit, but 'k' (result count) is left unexplained, which is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool recalls Zeug's internal writings (notes, analysis, compiled research) and explicitly contrasts this with search for 'why did we decide X' questions, effectively distinguishing it from a key sibling. The verb 'Recall' and resource are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: 'Use this (not search) for "why did we decide X" questions.' Also includes a parameter-based guidance ('Set wide=true to also include articles and social posts'). This is clear and actionable for an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rememberA

Record a durable fact — a pitfall, decision, or incident — so it survives the session. Becomes searchable after the next ingest run. Never store secrets. Requires the zme:write scope in OAuth mode.

NameRequiredDescriptionDefault
textYes
agentNozme-mcp
titleNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (all false, providing no safety profile), the description discloses meaningful behavior: the fact survives the session, becomes searchable only after the next ingest run (eventual consistency), and requires OAuth zme:write scope. It also adds a security rule (never store secrets). This is rich, non-obvious 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, each adding distinct value: what it records, when it becomes searchable, and security/auth constraints. No redundant wording, and the core purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 scalar params) and the presence of an output schema, the description covers all essential aspects: purpose, durability, indexing behavior, security caveat, and auth requirement. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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 of the three parameters. The text parameter is somewhat inferable from 'Record a durable fact,' but agent and title have no semantic guidance, so the description fails to compensate for the schema's lack of detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses 'Record a durable fact' — a specific verb and resource — and clearly distinguishes this write tool from the retrieval siblings (search, fetch, near, recall, why). The types of facts (pitfall, decision, incident) further refine the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context for when to use the tool (recording durable facts rather than ephemeral ones) and includes important constraints (never store secrets, requires zme:write scope). It does not explicitly name an alternative for retrieval, but the mention of searchability after ingest implies that search is for later use, which is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

whyA
Read-onlyIdempotent

Causal chain between two entities in the knowledge graph, e.g. why('kimi CLI 0.27.0', 'loop.ts CLI_COMMANDS fix'). Use canonical names.

NameRequiredDescriptionDefault
max_hopsNo
to_entityYes
from_entityYes

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the requirement for canonical names but does not disclose behaviors like return format (though output schema exists) or handling of missing entities. Adequate disclosure for a safe, read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with a useful example and clear instruction. Every word contributes to understanding, and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema and annotations, but the description omits semantics for the optional max_hops parameter and lacks explicit guidance on when to use 'why' versus siblings. The example is helpful but the overall picture is incomplete for a three-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description only clarifies from_entity and to_entity via the example. The max_hops parameter is completely unaddressed, leaving its purpose and effect undocumented. This is a notable gap given the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a causal chain between two entities in the knowledge graph, with a concrete example. This distinguishes it from sibling tools like search or fetch by focusing on causal relationships.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The instruction to use canonical names is explicit and aids correct invocation. The example demonstrates the intended argument order. However, it does not explicitly state when to use 'why' over siblings or mention any exclusions, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

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

  1. 6 tool updatesv1.1.0
    • First observedfetch
    • First observednear
    • First observedrecall
    • First observedremember
    • First observedsearch
    • First observedwhy
Deploy Server
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A3.8/5.0

Scored across 6 tools

Disambiguation4/5

Each tool targets a distinct operation: search is for broad knowledge base lookup, recall is specifically for Zeug's own notes, near and why explore the knowledge graph from different angles (neighborhood vs. causal paths), fetch retrieves full content for search hits, and remember writes new facts. Minor overlap exists between search and recall, but the descriptions clearly partition them.

Naming Consistency4/5

All tool names are single lowercase words, giving a clean, consistent visual style. However, the names mix verbs (search, fetch, recall, remember) with non-verbs (near, why), which slightly weakens the semantic consistency of the naming convention.

Tool Count5/5

With 6 tools, the set is well-scoped for a knowledge management server. Each tool addresses a distinct need (lookup, detail retrieval, graph exploration, self-notes, causal analysis, and memory writing), with no apparent redundancy.

Completeness4/5

The main workflows are covered: searching and retrieving content, exploring entity relations, recalling internal notes, tracing causality, and recording durable facts. Missing capabilities like updating or deleting existing facts are minor and don't block primary use cases.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Cairn

    johnmontejano
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI tools to query a user's private, locally stored memories (notes, documents) with source citations, using the MCP protocol.
    29 npm
    MIT

  • LLM Second Brain

    philadelfic
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables LLM clients to read, search, create, update, and delete notes in a self-hosted shared memory bank over MCP, using hybrid vector and full-text search with optional summarization.
    4
    MIT

  • Spomory

    yliuai
    A
    license
    A
    quality
    A
    maintenance
    Enables personal AI memory management through MCP tools for adding, searching, exporting, and deleting memories, with knowledge-graph retrieval and multi-hop association for clients like Claude Desktop and Cursor.
    6
    1
    Apache 2.0

  • knowledge-base-server

    nStavrou10
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI agents to share persistent, self-improving memory by ingesting, classifying, synthesizing, and retrieving knowledge from Obsidian vaults, code, documents, transcripts, bookmarks, and sessions through MCP and REST interfaces with token-optimized search.
    14 npm
    MIT