EleSync is an MCP server that gives AI assistants persistent, shared access to a local markdown vault for reading, writing, and managing memories across clients like Claude, ChatGPT, and Gemini. With it, you can:
Search memories: Find information using hybrid keyword/semantic search, filtering by source, type, and scope.
List and search projects: View available project workspaces and recall memories within a specific project.
Store and update memories: Save facts, preferences, or project state with custom content, tags, types, scopes, and optional templates; mark new memories as superseding old ones to track changes.
Delete memories: Remove a memory by its ID or prefix.
Get vault summaries: See totals of memories by source and type.
Manage scopes: List accessible memory compartments and their counts.
Detect conflicts: Surface contradictory facts from different AI sources.
View history: Examine the full supersession chain of a memory—every prior version and when it changed.
Audit operations: Review all read, write, and delete activity when audit logging is enabled.
EleSync gives you a private workspace that your AI tools can share.
When every AI assistant keeps a separate history, you repeat the same background, preferences, decisions, and project details over and over. EleSync keeps the durable context you choose in a local vault, then lets approved assistants use that context with explicit project and scope boundaries.
Start a project with one assistant, continue it with another, and keep the context in a folder you control.
Your local vault
↓
Memories and imported history
↓
Projects, knowledge, tasks, decisions, and handoffs
↓
Approved AI assistantsNo EleSync account, hosted cloud database, e-mail registration, telemetry, subscription, or mandatory cloud sync is required.
Related MCP server: auxly-memory-cli
A new user should be able to go from installation to a useful AI workspace like this:
Choose a vault. Pick the local folder where EleSync will keep your workspace.
Protect access. Add a local dashboard username and password when you need remote or shared-device access.
Import AI history. Bring in ChatGPT, Claude, Gemini, WhatsApp, or other supported exports and review what will become durable context.
Create a project. Give your memories a purpose and a boundary.
Connect an assistant. Connect Claude Desktop locally, or use a secure HTTPS/OAuth flow for a remote assistant such as ChatGPT, Gemini, or Grok.
Test recall. Ask your assistant: What useful context can you retrieve from EleSync?
The dashboard includes a guided first-launch wizard and progress tracking for these steps.
Memory: gives assistants continuity across conversations and providers.
Projects: give context purpose, organization, and boundaries.
Knowledge: stores reusable knowledge sheets, tasks, decisions, and handoffs.
MCP/connectors: let approved AI assistants participate in the workspace.
Imports: bring existing AI history, documents, and WhatsApp conversations into one place.
PWA/mobile: capture and access the workspace from a phone while your computer runs EleSync.
Privacy: keeps the vault local-first and makes sharing explicit.
Important: when you connect an AI assistant, that assistant may read the context you make available to it. Use project boundaries, scopes, read-only permissions, and separate vaults when you need stronger limits.
The dashboard is the center of the workspace: memories, projects, imports, connection health, and mobile access are all reached from one place.
The product workflow is:
Area | What you use it for |
Import | Upload ChatGPT, Claude, Gemini, WhatsApp, JSON, CSV, Markdown, TXT, or ZIP exports. |
Memories | Search, review, edit, and organize imported and saved context. |
Projects | Collect memories, knowledge sheets, tasks, decisions, and handoffs. |
Connect AI | Configure local Claude Desktop or secure remote AI connections. |
Connection Health | See whether the vault, dashboard security, local clients, and remote setup are ready. |
PWA/mobile | Capture text, links, and imports from a phone. |
Local-first: notes and the search index live in the vault on your computer.
User-controlled: you choose the vault folder, backups, and what becomes durable.
No mandatory cloud account: normal local use works without an EleSync cloud service.
Optional encryption: encrypted vaults use Argon2id and XSalsa20-Poly1305 at rest; plaintext remains the default for portability.
Scoped AI access: client grants can limit which memory scopes an assistant can read or write.
Project isolation: project-bound connections cannot recall or modify memories outside their project.
Reviewable imports: imported conversations and WhatsApp messages can be reviewed before saving.
Download the latest Windows installer, run it, and open EleSync when installation finishes.
The installer asks where to keep the vault and visibly lists the AI assistants available from Connect AI after installation:
ChatGPT · Claude · Gemini · Grok · Perplexity · Copilot · DeepSeekClaude Desktop is the optional local connection that can be pre-wired during installation. Remote assistants require your authorization and a secure HTTPS connection, so the installer does not silently configure them.
scoop install https://raw.githubusercontent.com/darknodebros/EleSync/master/elesync.jsonUpdate later with:
scoop update
scoop update elesyncFor macOS, Linux, or users who prefer Python tooling:
pipx install elesync
ele webRequires Python 3.10 or newer. You can also use pip install elesync.
Standalone Windows, macOS, and Linux builds are attached to each GitHub release.
From the dashboard:
Open Import.
Choose a supported file or drop it into the import area.
Review the detected format and privacy information.
For WhatsApp, filter by sender and approve only the messages you want to keep.
Save the full conversation or selected durable memories.
Open Memories to search what was imported.
Supported formats include:
JSON · CSV · TXT · Markdown · ZIP · WhatsApp exports · Grok exportsImports are local. Nothing becomes durable project knowledge until the user saves or approves it.
Open Projects, create a project, and give it a short purpose such as:
Japan trip planning
Product launch
Biology assignment
EleSync workspaceInside a project you can:
Add existing memories
Save knowledge sheets
Track tasks
Record decisions
Leave AI handoffs
Set AI read/write/conversation permissions
Generate a project-specific local Claude connection
From a project page, choose the Claude provider and select Generate project connection. EleSync creates a command like:
ele --vault "D:\notes" onboard --target claude-desktop --project PROJECT_ID --name elesync-project-a1b2c3d4Run the command, restart Claude Desktop, and use the entry named:
elesync-project-a1b2c3d4This entry is project-bound. Memories saved through it are attached to the selected project.
It can coexist with a general elesync entry; remove or disable the general entry when you
need strict project-only visibility.
Remote assistants require a public HTTPS origin and provider authorization. Use the Connect AI page to generate the current setup instructions. EleSync will show:
MCP server URL
Secure authentication details
Local server command
Tunnel/reverse-proxy target
Connection verification result
Do not use 127.0.0.1, a private LAN address, or the dashboard port as a public provider URL.
EleSync can be installed on a phone without a separate mobile app:
Start EleSync on your computer with ele web.
Open Use on another device in the dashboard.
Put your phone and computer on the same Wi-Fi network.
Open the displayed address on your phone.
Choose Add to Home Screen or Install app.
The computer must be running for live vault access. The PWA supports shared text and link capture, encrypted offline drafts, automatic retry, and mobile imports. Do not expose the dashboard publicly without HTTPS and a passcode.
ele web # open the local dashboard
ele doctor # check installation health
ele import memories.json # import exported memories or notes
echo "I prefer dark mode" | ele import -
ele remember "Prefer short answers with examples"
ele recall "how should my AI answer me?"
ele sync # rebuild the local search index
ele summary # show a vault summaryAdvanced commands cover encryption, backups, USB vaults, scopes, conflict resolution, HTTP serving, and client wiring. See SETUP.md for the full walkthrough.
Run:
ele doctorCommon fixes:
If the dashboard does not open, run ele web and copy the error.
If an AI assistant cannot see memories, restart it after setup.
If search looks stale, run ele sync.
If an import looks wrong, keep the original export and check its source format.
If a remote connector is rejected, verify HTTPS, the public /mcp URL, the tunnel target,
and the authentication state in Connection Health.
EleSync is at 1.24.18 (904 tests, ~12,500 LOC). The current product focus is stabilization: bug fixing, UX polish, documentation, first-run completion, privacy clarity, and reliability.
MIT. See LICENSE.
View the audit trail of operations on this vault. Shows who did what
and when — useful for reviewing which AI clients are reading or writing
memories. Audit logging is enabled by default; set ELESYNC_AUDIT=0 to disable it.
last limits the number of entries (newest first).
operation filters to a specific op (REMEMBER, RECALL, FORGET, SCOPE, STATUS).
client filters to a specific client label.
| Name | Required | Description | Default |
|---|---|---|---|
| last | No | ||
| client | No | ||
| operation | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It explains default audit logging, the ELESYNC_AUDIT=0 disable option, and the order/filter behaviors. It omits return format, but an output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and then provides compact parameter explanations. Every sentence adds distinct value, including the default logging behavior and filter semantics, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with optional parameters and an output schema; the description covers purpose, filters, defaults, and configuration sufficiently. It does not explicitly compare to the sibling `history` tool, but overall it provides enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description explicitly explains all three parameters: `last` limits entries newest first, `operation` filters to specific ops, and `client` filters by label. This fully compensates for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'View the audit trail of operations on this vault.' It further clarifies the use case for reviewing AI clients, which differentiates it from sibling tools like recall or remember.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the tool is 'useful for reviewing which AI clients are reading or writing memories,' providing clear context for when to use it. It does not explicitly name alternative tools or exclusions, but the context is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Surface facts in the vault that look like they're about the same thing but disagree (e.g. two different stated locations), each with its source and date. Use this to spot stale/contradictory memory and confirm with the user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool surfaces facts with source and date, implying no side effects. It's transparent about its read-only nature but could explicitly state non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first defines the action with an example, second provides usage guidance. Both sentences are essential and front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is complete. It explains what the tool returns (facts with source and date) and its use case. Sibling tools further clarify its niche.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. Per guidelines, baseline is 4. The description adds no parameter info, which is acceptable given no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool surfaces conflicting facts (different locations) with source and date, distinguishing it from siblings like 'recall' or 'list_projects'. It provides a concrete example and specifies the verb 'surface' and resource 'vault'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool to 'spot stale/contradictory memory and confirm with the user.' While it doesn't list alternatives or when not to use, the context of sibling tools implies its unique role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a memory by id (full or 8-char prefix shown by recall).
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Delete' which implies destructive action, but it does not disclose whether deletion is permanent, reversible, requires auth, or has any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with efficient structure: action first, then parenthetical clarification. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no nested objects) and presence of an output schema (implied complete), the description adequately covers the core functionality. However, lacks details on failure modes or return behavior, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description adds valuable context: the id can be full or an 8-character prefix from 'recall'. This clarifies the parameter's format beyond the schema's simple 'string' type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a memory') and the resource ('by id'), distinguishing it from siblings like 'recall' (retrieve) and 'remember' (create). It also specifies the id format (full or 8-char prefix), which adds precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use (to delete a memory) and provides the id format hint from recall. However, it lacks explicit 'when not to use' or mention of alternatives, though the purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the supersession history of a memory (id or 8-char prefix): every
version that led to or replaced it, oldest first, with when each changed.
This is the "what was true when" view — use it to see what a fact used to
be after a memory was superseded (via remember(..., supersedes=...) or by
resolving a conflict).
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It describes showing history, ordering, and input format, but does not mention read-only nature, auth, or rate limits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action, no redundant words. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 1 parameter and output schema present, the description covers the key aspects of input and output without needing to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description adds value by specifying 'memory id or 8-char prefix', which clarifies the parameter beyond the schema's simple string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Show the supersession history of a memory' with specific details on ordering and content, distinguishing it from siblings like recall and audit_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'what was true when' view, use to see past facts after supersession via `remember(..., supersedes=...)` or conflict resolution. Lacks explicit when-not-to-use but is still helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's EleSync projects and their short ids. Use this before
recall_project when the user refers to a project by name.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries the burden. It states it lists projects, which implies a read operation, but doesn't disclose any potential side effects or authentication requirements. For a simple list tool, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by usage guidance. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool complexity is low (0 params, output schema exists). Description covers purpose and usage adequately, leaving output details to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds meaning by specifying the resource (EleSync projects) and what is returned (short ids).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists EleSync projects and their short ids. It distinguishes from sibling recall_project by indicating its use before that tool, but doesn't differentiate from all siblings like list_scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use: 'Use this before recall_project when the user refers to a project by name.' This provides clear context and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the memory scope compartments this client can see, with how many
memories each holds. general is the default, everyone-can-see bucket.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that scopes include a default 'general' bucket, but does not cover authorization, side effects, or rate limits. Adds some context but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action. Every sentence adds value with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. The description adequately explains the tool's purpose and output for a simple zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and per guidelines the baseline is 4. The description adds meaning about what is listed (scopes and counts), which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists memory scope compartments with memory counts, using specific verb 'List' and resource 'memory scope compartments'. It distinguishes from siblings like 'list_projects' and 'recall' by focusing on scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates the tool is for viewing scopes and their memory counts, but provides no explicit guidance on when to use it versus alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summary of what's in the vault: totals by source and type (limited to the memories this client's scope can see).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the scope limitation but does not discuss mutability, rate limits, or other behavioral traits. For a read-only summary tool, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded with the core purpose. Every word adds value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and no parameters, the description adequately covers the tool's purpose and scope limitation. It is complete enough for a simple summary tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. The description adds no parameter information, which is acceptable since none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a summary of vault contents with totals by source and type, and notes scope visibility. It is specific but does not explicitly differentiate from sibling tools, though its function is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like recall or list_projects. The description implies it is for an overview, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the approved project knowledge sheets, tasks, decisions, handoffs, and collected memories as a compact context package.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only lists the contents of the returned package and does not mention potential side effects, authentication requirements, rate limits, pagination, or what happens if the project_id is invalid. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that efficiently conveys the tool's purpose without redundant words. It is well-front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with one parameter and an output schema, so the description covers the core function. However, the lack of differentiation from siblings like 'recall_project' and the absence of any usage context leave the description incomplete for an agent deciding between tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'project_id' parameter beyond its name and type in the schema. The description also does not clarify whether the ID is a numeric or string identifier, or whether it refers to a project name or internal ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Return') and specifies the resource ('approved project knowledge sheets, tasks, decisions, handoffs, and collected memories') with the qualifier 'compact context package'. However, it does not distinguish itself from the sibling tool 'recall_project', which likely also retrieves project-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'recall_project' or 'recall'. It merely states what the tool returns without any contextual use cases, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the user's unified memory across all AIs. Use this at the start of
a task to recover context. source filters to one AI (chatgpt/claude/gemini);
type filters by fact/preference/project/relationship/conversation/note.
semantic_weight (0.0–1.0) tunes hybrid search: 0.0 = pure keyword,
1.0 = pure semantic, 0.5 = equal. Use -1.0 (default) for the config
default. Results are limited to the memory scopes this client is
allowed to see.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| query | Yes | ||
| source | No | ||
| semantic_weight | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses result scoping ('limited to the memory scopes this client is allowed to see'), explains semantic_weight behavior (0.0-1.0 tuning, default -1), and implies read-only behavior for a search. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads purpose and usage, then systematically explains parameters. Every sentence adds value, no fluff or repetition. It is efficiently structured for quick agent understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (not shown), the description need not cover return values. It covers input parameters, behavior (scoping, hybrid search), and defaults. Could be more complete by mentioning result ordering or pagination, but overall sufficient for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for source, type, and semantic_weight (e.g., 'filters to one AI', 'tunes hybrid search'). It does not explain the limit parameter, which appears only in schema with default 8. Still, most parameters benefit from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the user's unified memory across all AIs, and specifies use at task start to recover context. It distinguishes from sibling tools like recall_project by implying it covers all AIs, and explains filtering by source and type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this at the start of a task to recover context, and explains parameter usage (source, type, semantic_weight). It does not explicitly mention when not to use or alternative tools, but the context is clear given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search only the chats and memories collected in one EleSync project.
Use the id from list_projects. This is safer and more relevant than a
whole-vault recall for project-specific work.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must convey behavior. It implies read-only search ('search only...in one project') and emphasizes safety, but does not detail rate limits, authentication, or error handling. The output schema covers return format, making it adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, source for project_id, and rationale. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and an output schema, the description covers scope, parameter source, and use case. Could mention non-destructive behavior explicitly, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions. The description only adds context for project_id ('Use the id from list_projects'), but query and limit receive no additional meaning beyond the schema's basic type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search only the chats and memories collected in one EleSync project,' providing a specific verb (search) and resource (chats and memories in a project), and distinguishes it from the whole-vault recall via sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use the id from list_projects' and explains that this tool is 'safer and more relevant than a whole-vault recall for project-specific work,' giving clear when-to-use and alternative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a new memory to the user's vault so every other AI can see it too.
Use for durable facts, preferences, project state — not throwaway chatter.
Pass your identity in source (e.g. 'claude', 'chatgpt', 'gemini') so
provenance and conflict detection work correctly across AIs.
scopes (comma-separated, e.g. "legal" or "writing,coding") puts the memory
in a compartment only clients granted that scope can read; omit it to make
the memory general (visible to all) unless this client has a default scope.
supersedes (a memory id or 8-char prefix) marks that this memory replaces
an older one when a fact changes rather than adds (a move, a rename, an
updated preference): the old memory is kept as history but hidden from
recall, and history can then show what changed and when.
template names a structure from the memory://templates resource and
applies its type/tags/scopes defaults; fields is a JSON object filling
that template's placeholders, e.g. {"who": "Ana", "date": "2026-07-25"},
which builds the content for you so repeated captures stay comparable.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| type | No | note | |
| fields | No | ||
| scopes | No | ||
| source | No | ai | |
| content | Yes | ||
| template | No | ||
| supersedes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses that memories are visible to other AIs, provenance via source, compartmentalization via scopes, replacement via supersedes, and template usage. Does not mention idempotency or rate limits, but covers key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Paragraph is well-structured, front-loaded with main purpose, then explains parameters in sentence order. Slightly long but each sentence earns its place. Could be more compact but remains clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, 0% schema coverage, no annotations, description covers workflow and parameter relationships. Does not explain return value but output schema exists. Complete enough for an AI to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates fully. Explains all 8 parameters: source (identity), scopes (compartment), supersedes (replacement), template+fields (structured data), content, tags, type. Gives usage examples for fields and supersedes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a memory to the user's vault for durable facts, preferences, project state. It distinguishes from siblings like recall, forget, history by focusing on creation. The verb 'Save' plus resource 'memory' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for use: durable facts not throwaway chatter. Explains how to use source, scopes, supersedes, template. Does not explicitly name alternatives like recall for retrieval or forget for deletion, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new durable document inside one EleSync project.
This is a mutating tool: it writes the title and body to local vault storage
and updates the project manifest. It does not send content to an AI provider,
and it does not overwrite an existing document; each call creates a new
document. project_id must identify an existing project and kind must be
one of knowledge, task, decision, or handoff. Call it only after the
user has approved saving the content. A project-bound connection can use this
only for its assigned project and only when it has project write permission.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| kind | No | knowledge | |
| title | Yes | ||
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden, and it delivers: declares itself a mutating tool, specifies storage side effects (writes to local vault, updates manifest), states what it does NOT do (no AI provider calls, no overwriting), and documents preconditions (existing project, valid kind, user approval, write permission). This is exemplary disclosure for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Each of its six sentences carries unique weight: purpose, mutation warning, storage side effects, non-AI assurance, idempotency guarantee, validation rules, approval precondition, and permission model. Zero filler words, logic gate final section is a nice touch. Perfectly proportioned for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with 4 parameters, 0% schema coverage, and no annotations, the description covers the full range: side effects, constraints, preconditions, permission requirements, and validation rules. The presence of an output schema means return-value documentation isn't needed. Nothing missing for an agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate — and it does meaningfully. It documents that `project_id` must reference an existing project and that `kind` accepts only four values (`knowledge`, `task`, `decision`, `handoff`), none of which are in the schema itself. The remaining params (title, body) are self-evident from the schema names, so minimal description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scoping: 'Create a new durable document inside one EleSync project.' It clearly distinguishes itself from siblings by noting it 'writes to local vault storage' and 'does not send content to an AI provider,' which differentiates it from recall/remember tools. The distinction is crisp and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Call it only after the user has approved saving the content,' plus permission constraints for project-bound connections. While it doesn't name sibling alternatives explicitly like 'use recall_project instead,' the alternatives guidance is implied by context. The exclusion of AI-provider sending and the statement that each call creates a new document clarify when NOT to worry about overwrites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.23.45project_contextsave_project_documentv1.20.6audit_logfind_conflictsforgethistorylist_projectslist_scopesmemory_statusrecallrecall_projectrememberEach tool has a distinct purpose: project_context vs recall_project, remember vs save_project_document, and memory-specific tools (forget, history, find_conflicts) are clearly separated. No overlaps that could confuse an agent.
Naming is inconsistent: some tools use verb-first patterns (recall, list, save, remember, forget), while others are noun-first or standalone nouns (project_context, memory_status, history, audit_log). The mix of underscore and single-word forms (e.g., list_scopes vs recall_project) further reduces predictability.
12 tools is a reasonable number for a server that combines memory management and project context. It covers the core operations without being overwhelming, though a few could potentially be merged.
Memory operations are well covered (create, read, update via supersedes, delete, search, status, audit). However, project tools lack update/delete capabilities for projects and documents, leaving a notable gap in lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Token-efficient MCP memory for Markdown vaults. Tiered search, GraphRAG, AI memories.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/darknodebros/EleSync'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
