A
licenseNot graded
qualityB
maintenanceMCP server providing persistent memory, semantic search, versioned storage, webhook fanout, and unified LLM routing for AI agents via FastAPI runtime with multiple backend options.
31
Apache 2.0
synapsis
by teamolimpo
Synapsis is a durable memory and handoff management server for agentic workflows, providing structured sessions, tasks, knowledge search, and multi-agent coordination.
Search — Unified full-text search across observations, tasks, handoffs, knowledge/wiki, sessions, and entities. Supports scoping, date filtering, result limits, and optional hybrid/embedding modes.
Session Management — Full lifecycle operations:
init(start session),observe(record events),context(retrieve current state),summarize/compress(reduce token usage), andtasks(list associated tasks).Task Tracking — Create tasks with priority, tags, and parent/child relationships; query/filter by status or text; update status and notes; log events; and compress task history.
Handoff Protocol — Create structured handoff documents (
new) with title, body, status, priority, references, and task links — producing searchable, durable records — and retrieve them (get).Consolidation — Distill unconsolidated observations into structured memory layers. Auto-mode triggers only when thresholds are exceeded (>20 unprocessed observations, observations older than 7 days, or >50 total); explicit full consolidation also available.
Knowledge Base — A dedicated wiki/knowledge layer automatically populated and indexed from structured handoffs, searchable alongside other memory domains.
Document Registry — Register file paths to receive a hash (
d_set), then resolve hashes back to file metadata or content at varying detail levels (d_get): metadata only, partial (first 500 chars), or full content.System Administration — Health checks, domain management, orphan cleanup, database vacuum, WAL checkpoint, FTS index management, and system statistics.
Click on "Install 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., "@synapsisinitialize session 'Sprint 5 planning' and create a task"
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.
synapsis
MCP Plugin for Grok Build — Durable agent memory + handoff discipline
Durable memory layer for Grok Build agents and multi-agent workflows.
Sessions, tasks, mandatory structured handoffs (/handoff), unified search across timeline + knowledge, automatic compression and hygiene.
Use durable structured memory instead of stuffing everything into the context window.
Install (Grok Build — 30 seconds)
grok plugin install teamolimpo/synapsis --trustThen in any chat:
Type
/handoff "Clear title of the piece of work"(recommended for significant work)Or
/synapsis init "topic",/synapsis search "...", etc.
Raw MCP tools are also available (namespaced synapsis__* — discover via the built-in search_tool first).
Unified durable team memory MCP + skills package, extracted as a focused, reusable plugin.
Synapsis is a standalone memory layer designed for agentic workflows and Grok Build. It was originally extracted from a larger internal project.
Works great with Grok Build (and any MCP-speaking agent system).
Why this exists
When you have multiple specialist agents (or subagents), the hard part is not creating the agents — it's making them hand work to each other reliably, keep shared context, audit what happened, and build up durable knowledge without losing it between sessions.
Synapsis solves that with:
Session + observation timeline with smart token compression and multi-level summarization.
Task tracking with state machine, events, and parent/child relationships.
Handoff protocol (
synapsis__hf) — every significant piece of work produces a structured, searchable handoff file (with optional Wiki contribution).Unified search across everything (observations, tasks, handoffs, knowledge/wiki chunks) with FTS5 + optional hybrid/embedding modes.
Knowledge / Wiki layer (chunks + search) that handoffs can feed automatically.
All backed by a single SQLite DB (
.synapsis/synapsis.dbby default — local, low-latency operational store) + handoff files and curated knowledge underLibrary/. The DB path is overridable viaSYNAPSIS_DB_PATH.
Library/ is the mount point for the private vault (teamolimpo/synapsis-vault). It is required for full durable handoffs and private knowledge (tensor-mill members). External contributors only cloning the public repo will not have it. See the "Tensor-mill / full memory setup" section below.
Related MCP server: memory-mcp
Quick Start with Grok Build
# Clone the focused package
git clone https://github.com/teamolimpo/synapsis.git
cd synapsis
uv sync
# Run Grok from inside this directory
grokGrok loads the synapsis MCP from the plugin manifest (plugin.json + .mcp.json present in the tree). This uses the exact same launch command and GROK_WORKSPACE_ROOT / GROK_PLUGIN_ROOT injection as when the plugin is installed in any consumer project (no more direct registration/launch "from this cartella" via project config).
In the TUI:
Type
/mcps(or use the MCP modal) — you should see synapsis.The tools will be namespaced:
synapsis__search,synapsis__session,synapsis__task,synapsis__hf,synapsis__d_set,synapsis__d_get, etc.
Tensor-mill / full memory setup (private vault)
The public repo is the environment (tools, rules, skills, public SOPs).
The private content (all handoffs, Wiki, projects, assets, private SOPs) lives in a separate repo (teamolimpo/synapsis-vault) that you symlink as Library/.
Quick one-command vault mount (after cloning both repos):
cd synapsis # the public clone
uv sync
# One of these two (both do the external symlink + prepare .synapsis/)
bash scripts/vault-mount.sh
# or the integrated command:
synapsis vault mountYou are now ready to go with your full work tool (durable /handoff, private search, projects/, etc.).
bash scripts/vault-check.sh/synapsis vault checkbash scripts/vault-doctor.shfor diagnosticsbash scripts/vault-unmount.shto remove the symlink safely
See also scripts/ for the other helpers and the plan in plans/vault-setup-automation-001.md.
Recommended Integration with Grok Build (2026+)
Instead of raw long search_tool + use_tool synapsis__xxx {...} sequences, use the project skills:
/handoff <title> ...— the mandatory structured handoff flow (recall first, proper hf + task log + observe, Wiki contribution support)./synapsis ...(or/mem) — general memory ops: init, search/recall, observe, task mgmt, health, consolidate, stats, hygiene.
These live in .grok/skills/ (version controlled) and appear in the slash menu.
Project rules are now properly loaded via the standard mechanism:
AGENTS.md(short, canonical entry point) + any*.mdunder.grok/rules/GROK.mdremains the detailed operational manual (tool-by-tool, examples, token strategies, full handoff discipline). The AGENTS.md points to it.
Automatic hygiene via project hooks (.grok/hooks/synapsis-hygiene.json):
On
Stop,PreCompact,SessionEnd: runssynapsis hygiene(dry consolidate + stats).First time you open the project with hooks you must trust it (or use the
/hooksmodal).
Basic usage example (tell the agent):
"Initialize a session with topic 'Porting handoff protocol' and then observe this decision: we chose synapsis as the package name."
Or simply: "Use /handoff for this piece of work."
Typical flow the memory expects:
/synapsis init "topic..."(or raw session init)Do work, record with observations or tasks
/handoff "Clear title" tref:T-XXX ...(or raw synapsis__hf + log)Later recall with
/synapsis search "..."or targetedsynapsis__search
Handoff files land in Library/Handoff/YYYY/MM/. Wiki contributions (from handoffs) land in Library/Wiki/.
See:
AGENTS.md(loaded project rules)GROK.md(full patterns and discipline).grok/skills/handoff/SKILL.mdandsynapsis/SKILL.mduv run python -m tools.synapsis --help(CLI for maintenance/hygiene)
The LLM client (historical note)
The multi-provider LLM client (tools/llm with Grok/Gemini/OpenRouter providers, batch, image support, etc.) was previously co-located in this repository during the initial extraction.
It has been moved out of the lean synapsis plugin distribution (see user request: LLM tools "non sono di casa" here). The full code now lives under:
~/TeamOlimpo/synapsis-extras/tools/llm/
If you need the LLM client for your TeamOlimpo work, import from the extras tree (or extract it later into its own small package). The synapsis plugin itself is now focused exclusively on the durable memory MCP, tasks/handoffs, knowledge chunking/indexing, and the /synapsis + /handoff skills.
Project layout (kept close to original for "as-is" fidelity)
synapsis/
├── .grok/
│ └── config.toml # project notes (MCP now exclusively declared via plugin .mcp.json; see file header)
├── .synapsis/ # Local low-latency runtime memory (gitignored)
│ └── synapsis.db # The hot operational SQLite store (sessions, tasks, observations, FTS5, ...)
├── tools/
│ ├── common/
│ │ └── paths.py # workspace + plugin-aware resolution (GROK_WORKSPACE_ROOT, Library, .synapsis)
│ ├── synapsis/ # The memory MCP (server, store, hf handoffs, search, consolidate, etc.)
│ └── knowledge_base/ # Chunking, entity extraction, hybrid search (used internally by synapsis for knowledge domain)
├── Library/ # Gitignored — curated/static/vault content (Handoff + Wiki)
│ ├── Handoff/
│ └── Wiki/
├── pyproject.toml
└── README.mdThe tools/ layout is preserved so that all internal imports (from tools.common.paths, from tools.synapsis.models, etc.) continue to work without modification. You can still run:
uv run python -m tools.synapsisexactly as before.
.synapsis vs Library (hot operational memory vs curated/vault content)
.synapsis/(default): low-latency local runtime store. Contains:synapsis.db(plus WAL/SHM) — sessions, observations, tasks, entities, FTS5, knowledge chunks, etc.config.yaml— optional local operational configuration for the whole synapsis instance (e.g. what to index underknowledge.include/knowledge.exclude). Fast local I/O by design. Fully gitignored.
Library/: the mount point for the private vault (teamolimpo/synapsis-vault). Contains all handoffs, Wiki, projects/, assets, and private SOPs. Required for tensor-mill members. Created/maintained with the simplevault-mountcommands above. Gitignored in the public repo (the symlink entry itself is never committed).
The split exists so that the very active DB (frequent small writes + searches) stays on fast local storage, while you can still keep handoffs and curated knowledge in a separate, possibly remote/slower vault.
tools/common/paths.py provides resolve_absolute() / resolve_relative() for symlink handling (mainly useful for Library parts).
Override the DB location anytime with the SYNAPSIS_DB_PATH environment variable (e.g. to point back at an old Library/System/Poros/synapsis.db or to a shared location). Handoff file location is currently under Library (see tools/synapsis/hf.py); this may evolve later.
Status & Relationship to original project
This repo is now the focused, lean distribution of the synapsis memory plugin for Grok Build:
Synapsis (the memory/handoff/knowledge system + chunk indexer libraries)
Supporting CLI, skills (
/synapsis,/handoff), hooks for auto-init + hygiene, and the full documented discipline (AGENTS.md + GROK.md).
The multi-provider LLM client was part of the initial extraction but has been moved to ~/TeamOlimpo/synapsis-extras/tools/llm/ (per decision that LLM tooling does not belong in the memory plugin surface).
Many of the concepts (mandatory handoffs, structured memory, quality gates, "handoff before you return control") translate well to agentic setups and subagent coordination patterns. The git workflow companion discipline (01- rule) also lives in the extras for TeamOlimpo adopters.
Contributing / Philosophy
If you extend this, try to keep the "handoff before you return control" spirit and make heavy use of the durable memory instead of stuffing everything into the agent's context window.
The handoff protocol and memory discipline are documented in GROK.md and AGENTS.md.
Grok Build Plugin & Marketplace (min install)
You can install synapsis as a first-class Grok Build plugin. This gives you:
The
synapsisMCP server (tools:synapsis__search,synapsis__session,synapsis__task,synapsis__hf,synapsis__consolidate,synapsis__admin,d_set/d_get).The project skills
/synapsisand/handoff(the recommended ergonomic interface — recall-first, handoff protocol, token-efficient usage, closing hygiene).
Install
# Direct (works for any git repo that is a valid plugin)
grok plugin install teamolimpo/synapsis --trust
# Or via a marketplace source
grok plugin marketplace add teamolimpo/synapsis
grok plugin install synapsis --trustThen:
/mcps→ you should see synapsis/skillsor/→/synapsisand/handoffappear/plugins→ details and enable/disable
The DB (.synapsis/synapsis.db) and optional Library/ for durable handoffs are resolved relative to your current project/workspace (plugin-aware paths), not inside the installed plugin.
Important for the working directory / launch folder:
When you do cd /my/project; grok, the official Grok signal for that working directory is the environment variable GROK_WORKSPACE_ROOT (with the compatible alias CLAUDE_PROJECT_DIR). These are documented in the official user-guide (hooks + workspace identity).
The synapsis plugin's .mcp.json now explicitly declares them so the MCP child process receives the correct value even when uv --directory ${GROK_PLUGIN_ROOT} is used for the plugin's own pyproject/venv selection.
tools/common/paths.py treats GROK_WORKSPACE_ROOT as the primary source of truth (before any cwd walking or marker discovery). Handoffs, Library/, .synapsis/, knowledge includes etc. will therefore land inside the directory you launched grok from.
Diagnostic aid: after you perform a handoff (or any synapsis tool that writes), inspectcat /tmp/synapsis-path-debug.log
It contains JSON lines with the pid, cwd seen by the MCP, the value of GROK_WORKSPACE_ROOT, __file__, plugin-context detection, chosen root and the exact reason. This is the easiest way to answer "why did it write outside my working directory?".
If the log shows that GROK_WORKSPACE_ROOT was absent and the effective cwd was the installed plugin dir (or a parent), re-launch with the env explicitly:
GROK_WORKSPACE_ROOT=$(pwd) grok(or SYNAPSIS_WORKSPACE=$(pwd) grok). The paths helpers honour it at the highest priority.
Dependencies and first run (important)
After grok plugin install, Grok checks out the code but does not run uv sync for you.
The .mcp.json uses uv run --frozen .... On the very first use of any synapsis tool/MCP after installation, uv will automatically create a .venv inside the plugin directory and install the dependencies from uv.lock.
This can take 30s–few minutes the first time (network + compilation of some packages). Subsequent launches are fast.
Make sure uv is in your PATH when you start Grok.
To make the first experience smooth, you can pre-sync manually after install:
# Find the actual installed location
grok plugin details synapsis
# Then sync (example)
uv --directory /path/that/grok/installed/synapsis sync --frozenThe same uv --directory ... run synapsis ... pattern works for the CLI (e.g. synapsis stats, synapsis vault mount, etc.) when using the plugin from outside a synapsis source tree.
Automatic init & hygiene (new with the plugin)
The plugin now ships hooks/hooks.json. When the synapsis plugin is installed + trusted:
On
SessionStart: it automatically runssynapsis knowledge init(via the plugin's uv) in your current workspace. This creates.synapsis/+ a starterconfig.yaml(withknowledge.includeforLibrary/Wiki/andLibrary/Handoff/, plus other defaults). No more manual init in every new project!On
Stop,PreCompact,SessionEnd: it runs the hygiene (dry consolidate + stats) automatically.
This is powered by GROK_WORKSPACE_ROOT + GROK_PLUGIN_ROOT (so everything targets the right launch directory + the installed plugin code).
You still get the full discipline (including explicit synapsis__session(act="init") / /synapsis init for tracking sessions, tasks and handoffs) — the plugin just removes the "I have to remember to set up the basics" friction.
See also the shipped /synapsis and /handoff skills.
For full synapsis discipline (AGENTS.md, rules, vault, etc.) you still copy/adopt the relevant pieces from this repo into your own project, or keep using the public clone as your "memory environment".
See also: the /synapsis and /handoff skills, uv run python -m tools.synapsis --help, and grok plugin validate / grok plugin details synapsis.
License
MIT (same as the original extraction source).
Made to be useful with Grok Build (and any MCP-speaking agent system). Feedback and improvements welcome — especially around making the memory layer even more powerful when combined with subagents and worktree isolation.
Available Tools
8 toolsadminD
System admin: health | domain | orphan | vacuum | stats | index | checkpoint.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| act | No | stats | |
| cmd | No | quick | |
| domain | No | ||
| on | No | ||
| ix | No | status | |
| dry | No | ||
| name | No | auto | |
| scope | No | all |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1.5/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no information about side effects, required permissions, or what actions are performed. It merely lists operation names without any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly brief—a single line listing operations—but for a tool with 8 parameters, this under-specification harms usability. It is concise at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no param docs, no annotations, output schema exists but unmentioned), the description is woefully incomplete. It fails to explain inputs, outputs, or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It does not mention any of the 8 parameters (act, cmd, domain, etc.) or their semantics, leaving the agent completely in the dark.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists actions like 'health', 'domain', 'orphan', etc., but does not clearly state an overall purpose or verb-resource pair. It is vague and resembles a menu rather than a coherent tool function.
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 provided on when to use this tool over siblings (e.g., consolidate, search). There is no context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
consolidateA
Distil unconsolidated observations into structured memory layers.
When auto=True (default), runs a lightweight auto-consolidation check
that only triggers actual compression when clearly needed (>20 unconsolidated
obs, obs older than 7 days, or >50 total obs in session). When auto=False,
runs the full explicit consolidation as before.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sid | No | ||
| days | No | ||
| dry | No | ||
| auto | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses auto-check conditions and difference between auto=True (lightweight) and auto=False (full explicit). No annotations exist, so description carries full burden. Could mention side effects (e.g., deletion of original observations).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences; first sentence states core purpose, subsequent sentences detail auto flag behavior. Efficiently front-loaded, though could tighten wording.
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?
Covers auto mechanism and thresholds, but omits parameter details (sid, days, dry). Has output schema, so return values may be defined there, but parameter lack reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0% and description only mentions 'auto' parameter (default=True). No explanation for sid, days, or dry parameters, leaving agent guessing their meaning and usage.
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?
Clear verb-resource pairing: 'Distil unconsolidated observations into structured memory layers.' Distinguishes from sibling tools (admin, search, session, etc.) which are unrelated.
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?
Describes two modes (auto=True/False) with explicit conditions for auto-trigger (e.g., >20 unconsolidated obs, obs older than 7 days). No explicit 'when not to use', but conditions clarify appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
d_getC
Resolve hash. l=1: meta. l=2: +500ch. l=3: full.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| h | Yes | ||
| l | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only hints at different result sizes per level but does not state whether the tool is read-only, destructive, or requires authentication. Behavioral traits remain unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (10 words), front-loading the main action. However, the cryptic abbreviations ('meta', '+500ch') sacrifice clarity for conciseness. It is structured but under-informative.
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 having an output schema (not shown) and only 2 parameters, the description fails to give context about what the different levels return, how the hash is used, or how this tool fits among 7 siblings. Completeness is poor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description minimally explains the 'l' parameter (levels 1-3) and implies 'h' is a hash. It adds some meaning for 'l' but not for 'h', leaving the hash format unspecified. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Resolve hash' which is a verb+resource, but the level explanations are cryptic ('meta', '+500ch', 'full') without defining what hash refers to. It does not distinguish from sibling tools like 'd_set' or 'search', leaving purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 like 'search' or 'hf'. No context about prerequisites, when not to use it, or what the levels imply for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
d_setC
Register file path. Returns hash.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| p | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits such as side effects, authentication requirements, or error conditions. For a registration operation, it is unclear whether the action is idempotent or what happens if the path already exists. Since no annotations are provided, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it sacrifices necessary detail for brevity. It is concise but insufficiently informative.
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?
Given the tool has an output schema, return values do not need further explanation. However, the description lacks essential context about the registration process, such as persistence, uniqueness, or potential side effects, making it incomplete for an agent to use correctly.
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 coverage, the description should compensate, but it only generically mentions 'file path'. The parameter 'p' is not explained beyond the schema, leaving users uncertain about format, valid values, or semantics.
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 states 'Register file path. Returns hash.' which clearly indicates the action (register) and the resource (file path) and hints at a return value (hash). However, it does not differentiate from sibling tools like d_get, which might also deal with file paths.
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 provided on when to use this tool versus alternatives, nor any context about prerequisites or conditions under which it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hfD
Handoff: act=new (create) | act=get (read). Compact params: act, st, prio, tk, q.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| act | No | new | |
| type | No | ||
| title | No | ||
| body | No | ||
| agent | No | ||
| tref | No | ||
| note | No | ||
| refs | No | ||
| devi | No | ||
| st | No | done | |
| prio | No | med | |
| task | No | ||
| ref | No | ||
| tk | No | ||
| q | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1.3/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but fails to disclose any behavioral traits such as side effects, permissions, or what happens during a handoff. Compact parameters like 'tk' (default 300) and 'q' are left unexplained, leaving the agent uninformed about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but not appropriately sized; it sacrifices necessary detail for brevity. Every sentence should earn its place, but here the minimal text leaves critical gaps. It is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 15 parameters, 0% schema coverage, and no annotations, the description is severely incomplete. It does not explain the tool's output (though output schema exists), nor does it provide enough context for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 lists 'act, st, prio, tk, q' as compact params without explaining their purpose, format, or constraints. For 15 parameters, the description adds no meaningful semantics beyond what the parameter names provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Handoff: act=new (create) | act=get (read)' which suggests two modes but does not clarify what a handoff is or what resource it operates on. The term 'handoff' is ambiguous without further context, and the description provides no elaboration beyond the act values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 alternatives like 'task' or 'session'. There is no mention of prerequisites, use cases, or conditions that would help an agent decide between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchC
Search knowledge, tasks, observations, entities, memory_layers, session, timeline, hf.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| scope | No | auto | |
| l | No | ||
| n | No | ||
| ref | No | ||
| since | No | ||
| tk | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only lists searchable domains but omits any behavioral traits such as whether the operation is read-only, harmful side effects, authentication requirements, rate limits, or result format. The agent has no insight into safety or behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one line) and front-loads the action 'Search', which is good. However, it is essentially a list of items separated by commas, which is clunky. No structural elements like bullet points or sections. Every word earns its place, but the format is suboptimal for rapid scanning.
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?
Given 7 parameters (1 required) and no output schema details in the description, the tool is inadequately documented. The description fails to explain how queries work, what results look like, or how parameters affect search. An output schema exists but is not referenced; the agent must infer semantics from names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. Required parameter 'query' is unexplained (type, expected content). Optional parameters like 'scope', 'l', 'n', 'ref', 'since', 'tk' are not mentioned at all. The agent must rely solely on parameter names and types, which are minimal (e.g., 'scope' is a string with no enum, 'l' integer default 1 without explanation).
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 states 'Search knowledge, tasks, observations, entities, memory_layers, session, timeline, hf.' which clearly identifies the tool as a search across multiple resources. However, it does not explicitly contrast with sibling tools like 'task' or 'hf', leaving some ambiguity about when to use this unified search vs. specific domain 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 usage guidelines provided. The description does not mention when to use this tool versus alternatives (e.g., sibling tools like 'task' for task-specific ops or 'hf' for HF-related queries). No context on prerequisites or situations where search is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sessionD
Session lifecycle: init | observe | context | summarize | compress | tasks.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| act | No | init | |
| sid | No | ||
| topic | No | ||
| tids | No | ||
| resume | No | ||
| tk | No | ||
| type | No | ||
| content | No | ||
| agent | No | Poros | |
| entities | No | ||
| hpath | No | ||
| tref | No | ||
| tkdc | No | ||
| tkrd | No | ||
| pid | No | ||
| l | No | ||
| force | No | ||
| lv | No | ||
| mtk | No | ||
| days | No | ||
| ml | No | ||
| dry | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
D1.3/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only lists lifecycle steps without mentioning side effects, safety, or mutability. A score of 1 is justified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but fails to convey essential information. It is under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 parameters, no annotations, and a complex schema, the description is severely incomplete. It does not cover return values or parameter behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to 22 cryptic parameters (e.g., tk, tkdc). Parameter semantics are completely opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Session lifecycle: init | observe | context | summarize | compress | tasks' lists possible actions but does not specify a clear verb-resource combination. It fails to distinguish from siblings like admin or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 provides no context for appropriate usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
taskC
Task lifecycle: create | query | update | log | summary | export | compress.
For act="update": prefer the short parameter "sts" (introduced for token reduction on frequent status changes/handoffs). "status" is accepted as fallback for compatibility.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| act | No | query | |
| desc | No | ||
| prio | No | medium | |
| owner | No | Poros | |
| status | No | pending | |
| tid | No | ||
| parent | No | ||
| tags | No | ||
| search | No | ||
| tag | No | ||
| since | No | ||
| limit | No | ||
| evts | No | ||
| sts | No | ||
| note | No | ||
| evt | No | ||
| details | No | ||
| hpath | No | ||
| fmt | No | ||
| days | No | ||
| ml | No | ||
| dry | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.2/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral aspects such as side effects, authentication requirements, rate limits, or whether actions are destructive. The agent cannot infer safety or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded with the action list. It wastes no words, but the brevity sacrifices necessary detail. It is minimally concise for a simple tool, but here the tool is complex.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (22 parameters, multiple actions, output schema), the description is severely incomplete. It does not explain the semantics of each action or parameter, nor the expected output beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 22 parameters and 0% schema description coverage, the description only explains 'sts' vs 'status' for the update action. All other parameters (act, desc, prio, etc.) lack any explanation, leaving the agent to guess their roles.
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 lists the actions (create, query, update, log, summary, export, compress) clearly, indicating the tool covers the task lifecycle. It differentiates from sibling tools like 'search' or 'admin' by focusing on task management, though not explicitly.
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?
The description only provides guidance for the update action, suggesting 'sts' over 'status'. No general guidance on when to use this tool compared to siblings, nor when to use specific actions like create vs. log.
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. Dates show when Glama detected each change.
8 tool updates
v0.1.0- First observed
admin - First observed
consolidate - First observed
d_get - First observed
d_set - First observed
hf - First observed
search - First observed
session - First observed
task
TDQS
C2.6/5.0
Disambiguation5/5
Each tool targets a distinct area (admin, consolidation, hash ops, handoff, search, session, task) with no overlapping purposes, ensuring agents can easily differentiate.
Naming Consistency3/5
Tool names mix full words (admin, consolidate), underscores (d_get, d_set), and abbreviations (hf). While readable, the inconsistent pattern may reduce predictability.
Tool Count5/5
Eight tools is well within the ideal range, each serving a clear and necessary function in the server's memory/agent domain.
Completeness4/5
The tool set covers core lifecycle operations for sessions and tasks, plus search and admin utilities. Minor potential gaps (e.g., explicit deletion) are acceptable given the scope.
Maintenance
ActivityInactive
ResponsivenessUnresponsive
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
1shared AI-context layer for teams — persistent memory your agents search and update over MCP
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA persistent, conflict-aware memory MCP server for AI coding assistants (Cursor, Claude Code).-
- FlicenseNot gradedqualityFmaintenanceA local-first, team-ready MCP server providing durable memory for LLM-based coding workflows with multiple storage backends and fast search.4-
- AlicenseBqualityBmaintenanceLocal-first memory server for AI coding agents that stores work sessions, tasks, and durable memories in Markdown files, exposed through MCP tools for session management and memory retrieval.10131MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/teamolimpo/synapsis'
If you have feedback or need assistance with the MCP directory API, please join our Discord server