Skip to main content
Glama
memorysyncio

MemorySync Cursor Starter

Official
by memorysyncio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

MemorySync Cursor Starter Template

Stop Cursor from forgetting your project architecture across chat restarts.

This repository is a production-ready starter template configured with MemorySync and the Model Context Protocol (MCP). It gives Cursor persistent, scoped memory across conversations, so you never have to re-explain your framework choices, database patterns, or pinned library versions.

What's Included

  • server.py: Runnable, zero-dependency standard MCP stdio server implementing the full Model Context Protocol (MCP 2024-11-05) for Cursor, Claude Desktop, and AI agents.

  • Dockerfile & docker-compose.yml: Containerized deployment running the MCP server over stdio.

  • .cursor/mcp.json: Preconfigured with MemorySync remote MCP endpoints (both memory and live zero-signup docs).

  • .cursorrules: Strict developer instructions instructing Cursor when to save decisions and how to recall them with zero context bloat.

  • setup.sh & setup.ps1: Automated 1-click cross-platform setup scripts for macOS, Linux, and Windows.

  • tools/inspect_memory.sh & tools/inspect_memory.ps1: Single-file, zero-dependency terminal memory inspector.

  • examples/minimal_mcp_client.py: Minimal Python example demonstrating how to interact with MCP programmatically.

Related MCP server: ContextFS

Running the MCP Server (stdio)

Run the server directly with Python 3:

python3 server.py

Or connect it to Claude Desktop / Cursor using stdio configuration:

{
  "mcpServers": {
    "memorysync": {
      "command": "python3",
      "args": ["/path/to/memorysync-cursor-starter/server.py"],
      "env": {
        "MEMORYSYNC_API_KEY": "your_api_key_here"
      }
    }
  }
}

Supported MCP Tools:

  • memorysync_search: Semantic search over persistent long-term memories with sub-50ms latency.

  • memorysync_add: Save a new durable memory, preference, or architectural decision.

  • memorysync_read_docs: Query official MemorySync API, SDK, and integration documentation on demand.

60-Second Setup

1. Clone this template

git clone https://github.com/memorysyncio/memorysync-cursor-starter.git my-agent-project
cd my-agent-project

2. Run Automated Setup

Option A: Local Terminal (macOS / Linux / Windows)

  • macOS / Linux:

    chmod +x setup.sh && ./setup.sh

  • Windows (PowerShell):

    powershell -ExecutionPolicy Bypass -File .\setup.ps1

Option B: Docker (Containerized Testing)

# Verify connection inside container
docker compose run --rm memorysync-starter

# Run programmatic Python client test
docker compose run --rm test

3. Open in Cursor

Open this folder in Cursor IDE:

cursor .

4. Verify MCP Connection

  1. Open Cursor Settings (Cmd + , or Ctrl + ,) > Features > MCP.

  2. You will see two active servers:

    • memorysync (https://mcp.memorysync.io/mcp) — For persistent memory storage & semantic search.

    • memorysync-docs (https://docs.memorysync.io/mcp) — Instant live documentation search without sign-up.

Terminal Memory Inspector

Inspect and verify saved memories directly from your terminal without opening a browser:

# macOS / Linux
./tools/inspect_memory.sh ping
./tools/inspect_memory.sh stats -k "ms_live_..."
./tools/inspect_memory.sh query "PostgreSQL configuration" -k "ms_live_..."

# Windows PowerShell
.\tools\inspect_memory.ps1 -Command ping
.\tools\inspect_memory.ps1 -Command stats -ApiKey "ms_live_..."
.\tools\inspect_memory.ps1 -Command query -Query "PostgreSQL configuration" -ApiKey "ms_live_..."

How It Works

+-------------------------------------------------------------+
|                       Cursor Composer                       |
+------------------------------+------------------------------+
                               | 1. Store Decision (e.g. "We use FastAPI async")
                               v
+-------------------------------------------------------------+
|                  MemorySync Remote MCP Server               |
|                  (https://mcp.memorysync.io)                |
+------------------------------+------------------------------+
                               | 2. Sub-50ms Hybrid Recall
                               v
+-------------------------------------------------------------+
|      Fresh Chat Session: Automatically applies past rule    |
+-------------------------------------------------------------+

  1. Zero Context Bloat: Injects ~45 tokens of exact recalled facts instead of 8,000+ tokens of raw chat history.

  2. Multi-Project Isolation: Memories are strictly scoped by project so your backend rules never leak into your frontend.

  3. Inspectability: Every recalled fact references a verifiable memory ID.

Documentation & Resources

Available Tools

7 tools
memorysync_addSave a durable project memoryA

Persist one fact so it survives after this conversation ends: an architectural decision, a convention the user asked you to follow, or a constraint that will still be true next session. Call this when the user states a lasting preference or you settle a design question. Do not call it for transient chat, for content already returned by memorysync_search, or for anything a later session would be misled by. Save one discrete fact per call rather than a conversation summary.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesOne self-contained fact, written so it still makes sense with no surrounding conversation. Write 'This project uses Postgres with SQLAlchemy 2.x', not 'we decided to use that one'. Pronouns and references to the current chat will not resolve in a later session.
sourceNoWhich client or agent observed this fact, used for attribution when two memories conflict. Defaults to 'cursor' if omitted.cursor
metadataNoOptional flat key-value tags used to narrow later searches, for example {"area": "database"}. Values should be short strings. Omit rather than passing an empty object.

Output Schema

ParametersJSON Schema
NameRequiredDescription
idYesIdentifier of the stored memory.
statusYesResult of the write, for example 'created'.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false (write operation), destructiveHint=false, and idempotentHint=false. The description adds valuable context: the fact persists across sessions and must be self-contained to avoid misleading later sessions. It also emphasizes durability without contradicting any annotation. The bar is lower due to annotations, but the description adds meaningful behavioral detail beyond them.

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

Conciseness5/5

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

The description is about 80 words and every sentence serves a purpose: it states the core function, provides trigger conditions, lists exclusions, and gives a structural guideline (one fact per call). It is front-loaded with the primary purpose and avoids fluff.

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

Completeness5/5

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

The tool has an output schema, so return values are defined elsewhere. The description fully specifies when to use it, what to persist, and how to structure the call. It covers all necessary operational guidance for an agent to invoke it correctly, leaving no critical information missing.

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 100% with thorough descriptions for all three parameters, including examples for text and metadata. The description reinforces the text parameter's requirement for self-contained facts but does not add parameter-specific semantics beyond what the schema already provides. Baseline 3 is appropriate given the high schema coverage.

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

Purpose5/5

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

The description uses a specific verb ('Persist') and a clear resource ('one fact') that survives conversation end, with concrete examples of valid facts (architectural decision, convention, constraint). It explicitly distinguishes itself from siblings by stating not to call for content already returned by memorysync_search, making its purpose unambiguous.

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

Usage Guidelines5/5

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

It gives explicit call conditions ('Call this when the user states a lasting preference or you settle a design question') and clear exclusions ('Do not call it for transient chat, for content already returned by memorysync_search, or for anything a later session would be misled by'). It also instructs to save one discrete fact per call, fully covering when and 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.

memorysync_decisionsList recorded decisions and contradictionsA
Read-only

Return memories that record decisions, along with any that contradict each other, so a superseded choice is visible rather than silently competing with the current one. Call this before proposing an architectural change, to check whether the question was already settled and why. This surfaces conflict between stored facts; memorysync_search returns matches without telling you when two of them disagree.

ParametersJSON Schema
NameRequiredDescriptionDefault
kNoMaximum decisions to return. Defaults to 10 if omitted.
queryNoOptional topic filter, for example 'caching'. Omit to list recent decisions across all areas.

Output Schema

ParametersJSON Schema
NameRequiredDescription
decisionsNoRecorded decisions, newest first.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context: it surfaces contradictions and intentionally makes superseded choices visible. It does not go into output details, but an output schema exists, so those details are not required here.

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

Conciseness5/5

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

Three sentences with no waste: the first states the core function, the second gives the use case, and the third differentiates from the sibling. The most important guidance is front-loaded.

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

Completeness5/5

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

For a read-only tool with zero required parameters, a full output schema, and a clear choice-when condition, the description is complete. Nothing an agent needs to decide whether and when to call it is missing.

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?

Input schema description coverage is 100%: both k and query already have meaningful descriptions. The description's 'caching' example adds a minor illustration but no real semantic lift beyond the schema, so the baseline of 3 applies.

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?

States a specific verb ('Return') and resource ('memories that record decisions, along with contradictions'), and clearly differentiates from memorysync_search by noting that search does not surface disagreements. An agent can distinguish this tool from its siblings immediately.

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

Usage Guidelines5/5

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

Gives explicit timing: 'Call this before proposing an architectural change, to check whether the question was already settled and why.' It also names the alternative tool and the deciding condition, making the selection rule unambiguous.

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

memorysync_forgetDelete memories (previews by default)A
DestructiveIdempotent

Permanently delete one or more memories by id. Use this when a stored fact is wrong or the user asks you to forget something - not to tidy up, because a deleted memory cannot be recovered. This previews by default: it reports what would be deleted and deletes nothing until dry_run is explicitly set to false. Confirm with the user before that second call. To find the ids to pass, use memorysync_search.

ParametersJSON Schema
NameRequiredDescriptionDefault
reasonNoShort note recorded in the audit log explaining why these memories were removed.
dry_runNoDefaults to true, which previews the deletion without performing it. Pass false only after the user has confirmed.
memory_idsYesIdentifiers of the memories to delete, from memorysync_search results.

Output Schema

ParametersJSON Schema
NameRequiredDescription
dry_runYesWhether this call only previewed.
deleted_idsNoIdentifiers affected.
deleted_countYesNumber deleted, or number that would be deleted when previewing.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds critical behavioral context beyond those annotations: deletion is permanent and unrecoverable, the tool previews by default and deletes nothing until dry_run is explicitly false, and a second call is required to actually delete. It also discloses that a reason is recorded in an audit log. This is exactly the kind of behavioral disclosure that helps an agent avoid irreversible mistakes.

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

Conciseness5/5

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

Three sentences, each earning its place: the first states the action and when to use it, the second explains the preview default and irreversibility, the third routes to the sibling for finding ids. The critical safety information (permanent, previews by default, confirm before second call) is front-loaded and prominent.

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

Completeness5/5

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

For a destructive mutation tool with an output schema and full schema coverage, the description covers everything an agent needs: what to delete, when to delete, how to find ids, the preview behavior, the confirmation requirement, and the irreversibility. The output schema handles return-value details, and annotations handle the safety profile. Nothing essential is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the dry_run default behavior in plain language ('previews by default... deletes nothing until dry_run is explicitly set to false') and by clarifying that memory_ids come from memorysync_search results. It also explains the purpose of the reason parameter (audit log). This goes beyond the schema's field-level descriptions.

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

Purpose5/5

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

The description states a specific verb ('Permanently delete') and resource ('one or more memories by id'), and immediately distinguishes the intended use case from a sibling ('not to tidy up'). It also names the sibling to use for finding ids (memorysync_search), so an agent can tell this tool apart from the other memory tools without opening schemas.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance ('when a stored fact is wrong or the user asks you to forget something'), an explicit when-not-to-use ('not to tidy up'), and names the alternative for finding ids (memorysync_search). It also instructs the agent to confirm with the user before the second call with dry_run=false, which is clear operational guidance.

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

memorysync_getRead one memory in fullA
Read-only

Fetch the complete stored record for a single memory id, including its text, tags, importance and timestamps. Use this after memorysync_search when a result looks relevant but the snippet is not enough to act on, or when you need the creation date to judge whether a fact is stale. Takes an id, not a search phrase - to find a memory by topic, call memorysync_search first and pass an id from its results.

ParametersJSON Schema
NameRequiredDescriptionDefault
memory_idYesIdentifier of the memory to read, taken from the id field of a memorysync_search result.

Output Schema

ParametersJSON Schema
NameRequiredDescription
idYesIdentifier of the memory.
tagsNoTags attached to this memory.
textYesThe stored fact in full.
created_atNoWhen the fact was first observed, for judging staleness.
importanceNoImportance score used in ranking.
updated_atNoWhen the record last changed.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already convey readOnlyHint and openWorldHint, lowering the bar. The description adds useful behavioral context by stating it returns the complete record with specific fields, and clarifies that it does not perform search. No contradiction with annotations.

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

Conciseness5/5

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

Three sentences with no filler: first states what the tool does, second gives concrete use cases, third clarifies the id requirement and routing to the sibling. Every sentence earns its place and the most important information is front-loaded.

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

Completeness5/5

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

For a single-parameter read tool with a rich schema, annotations, and an output schema, the description covers purpose, usage timing, alternative routing, and parameter semantics. Nothing essential for correct invocation is missing.

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 100%, so the schema already documents memory_id thoroughly. The description reinforces that the id comes from memorysync_search and must not be a search phrase, which adds operational nuance but no new format or syntax details beyond the schema.

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

Purpose5/5

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

The description uses a specific verb ('Fetch') and names the exact resource ('complete stored record for a single memory id'), then lists the fields returned. It clearly distinguishes itself from memorysync_search by emphasizing this takes an id, not a search phrase.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool: after memorysync_search when a snippet is insufficient, or when needing creation date to assess staleness. It also gives a clear exclusion, directing users to memorysync_search for topic-based lookup, and names the alternative.

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

memorysync_read_docsRead MemorySync product documentationA
Read-only

Look up MemorySync's own public documentation: REST endpoints, SDK usage, MCP configuration, and integration guides. Call this before writing MemorySync integration code, so method names and parameters come from current docs rather than recall. Returns documentation text for the requested topic. This reads MemorySync product documentation only - to retrieve facts about the user's own project, use memorysync_search instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
topicYesDocumentation topic or page slug, for example 'cursor', 'claude-code', 'langgraph', 'n8n', 'multi-tenant', or 'quickstart'. An unrecognised topic returns the closest matching page rather than an error, so check the returned url before relying on the content. Pass one topic per call.

Output Schema

ParametersJSON Schema
NameRequiredDescription
urlNoCanonical documentation URL for the topic.
topicYesTopic that was resolved.
contentYesDocumentation text as Markdown.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark the tool read-only and open-world, and the description adds meaningful context beyond those annotations: it limits the scope to vendor product documentation, states that documentation text is returned, and the schema adds that unrecognized topics resolve to the closest-matching page. There is no contradiction with the annotations.

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

Conciseness5/5

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

Three sentences with the purpose and content scope front-loaded, usage timing in the middle, and sibling disambiguation at the end. Every sentence earns its place; there is no filler or redundant restating of the title.

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

Completeness5/5

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

For a one-parameter, read-only documentation lookup with an output schema and safe annotations, the definition fully covers scope, timing, return behavior, and sibling routing. Nothing an agent needs to invoke it correctly is missing.

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?

The top-level description only refers to a 'requested topic,' but the schema covers the single topic parameter 100%, including examples, slug format, closest-match behavior, and a one-topic-per-call instruction. Per the baseline rule, high schema coverage makes the description's lack of additional parameter detail sufficient.

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?

Uses a specific verb ('look up') plus a precise resource ('MemorySync's own public documentation') and enumerates the content areas covered. It also explicitly contrasts with memorysync_search, so the agent can disambiguate the two read tools without opening their schemas.

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

Usage Guidelines5/5

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

Tells the agent to call this before writing MemorySync integration code and names memorysync_search as the alternative for retrieving facts about the user's own project. This is an explicit when-and-when-not rule rather than leaving the choice to inference.

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

Tool Schema Changelog

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

  1. 4 tool updatesv1.0.3
    • Addedmemorysync_decisions
    • Addedmemorysync_forget
    • Addedmemorysync_get
    • Addedmemorysync_related
  2. 3 tool updatesv1.0.2
    • Changedmemorysync_add7 fields changed
      • changedInput schema / properties / metadata / description
        Previous value: -"Optional key-value tags, for example {\"area\": \"database\"}, to narrow later searches."New value: +"Optional flat key-value tags used to narrow later searches, for example {\"area\": \"database\"}. Values should be short strings. Omit rather than passing an empty object."
      • addedInput schema / properties / metadata / examples
        Added value: +[
+  {
+    "area": "database"
+  },
+  {
+    "area": "api",
+    "scope": "public"
+  }
+]
      • changedInput schema / properties / source / description
        Previous value: -"Which client or agent observed this, used for attribution when memories conflict."New value: +"Which client or agent observed this fact, used for attribution when two memories conflict. Defaults to 'cursor' if omitted."
      • addedInput schema / properties / source / examples
        Added value: +[
+  "cursor",
+  "claude-code",
+  "ci"
+]
      • changedInput schema / properties / text / description
        Previous value: -"One self-contained fact, written so it still makes sense with no surrounding conversation."New value: +"One self-contained fact, written so it still makes sense with no surrounding conversation. Write 'This project uses Postgres with SQLAlchemy 2.x', not 'we decided to use that one'. Pronouns and references to the current chat will not resolve in a later session."
      • addedInput schema / properties / text / examples
        Added value: +[
+  "This project uses Postgres with SQLAlchemy 2.x",
+  "All API errors must return RFC 7807 problem details"
+]
      • addedInput schema / properties / text / minLength
        Added value: +1
    • Changedmemorysync_read_docs3 fields changed
      • changedInput schema / properties / topic / description
        Previous value: -"Documentation topic or page slug, for example 'cursor', 'claude-code', 'langgraph', 'n8n', 'multi-tenant', or 'quickstart'."New value: +"Documentation topic or page slug, for example 'cursor', 'claude-code', 'langgraph', 'n8n', 'multi-tenant', or 'quickstart'. An unrecognised topic returns the closest matching page rather than an error, so check the returned url before relying on the content. Pass one topic per call."
      • addedInput schema / properties / topic / examples
        Added value: +[
+  "cursor",
+  "multi-tenant",
+  "quickstart"
+]
      • addedInput schema / properties / topic / minLength
        Added value: +1
    • Changedmemorysync_search4 fields changed
      • changedInput schema / properties / k / description
        Previous value: -"Maximum number of memories to return. Use a small value; ranked results degrade after the top few."New value: +"Maximum number of memories to return. Defaults to 5 if omitted. Ranked results degrade after the top few, so raise this only when surveying everything known about an area rather than answering one question."
      • changedInput schema / properties / query / description
        Previous value: -"Natural language description of the fact you are looking for, for example 'which ORM does this project use'."New value: +"Natural language description of the fact you are looking for, for example 'which ORM does this project use' or 'deployment target'. Phrase it as the topic you need, not as a question to the user. Matching is semantic, so exact wording from the original memory is not required. An empty or single-word query returns weak matches; prefer a short phrase."
      • addedInput schema / properties / query / examples
        Added value: +[
+  "which ORM does this project use",
+  "API error handling convention"
+]
      • addedInput schema / properties / query / minLength
        Added value: +1
  3. 3 tool updates
    • Changedmemorysync_add6 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / metadata / additionalProperties
        Added value: +true
      • changedInput schema / properties / metadata / description
        Previous value: -"Optional key-value metadata dictionary."New value: +"Optional key-value tags, for example {\"area\": \"database\"}, to narrow later searches."
      • changedInput schema / properties / source / description
        Previous value: -"Origin of the memory (default: cursor)."New value: +"Which client or agent observed this, used for attribution when memories conflict."
      • changedInput schema / properties / text / description
        Previous value: -"The exact fact, convention, or architectural decision to persist."New value: +"One self-contained fact, written so it still makes sense with no surrounding conversation."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "id": {
+      "description": "Identifier of the stored memory.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Result of the write, for example 'created'.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "status"
+  ],
+  "type": "object"
+}
    • Changedmemorysync_read_docs3 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / topic / description
        Previous value: -"Topic to look up (e.g., 'cursor', 'mcp', 'langgraph', 'n8n', 'multitenancy')."New value: +"Documentation topic or page slug, for example 'cursor', 'claude-code', 'langgraph', 'n8n', 'multi-tenant', or 'quickstart'."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "content": {
+      "description": "Documentation text as Markdown.",
+      "type": "string"
+    },
+    "topic": {
+      "description": "Topic that was resolved.",
+      "type": "string"
+    },
+    "url": {
+      "description": "Canonical documentation URL for the topic.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "topic",
+    "content"
+  ],
+  "type": "object"
+}
    • Changedmemorysync_search6 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / k / description
        Previous value: -"Maximum number of memories to return (default: 5)."New value: +"Maximum number of memories to return. Use a small value; ranked results degrade after the top few."
      • addedInput schema / properties / k / maximum
        Added value: +50
      • addedInput schema / properties / k / minimum
        Added value: +1
      • changedInput schema / properties / query / description
        Previous value: -"Natural language query to retrieve relevant memories for."New value: +"Natural language description of the fact you are looking for, for example 'which ORM does this project use'."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "description": "Number of memories returned.",
+      "type": "integer"
+    },
+    "results": {
+      "description": "Matching memories, most relevant first.",
+      "items": {
+        "properties": {
+          "created_at": {
+            "description": "When the memory was first observed, for judging staleness.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Stable identifier, usable with memorysync_add metadata or for later reference.",
+            "type": "string"
+          },
+          "score": {
+            "description": "Relevance score for this query.",
+            "type": "number"
+          },
+          "text": {
+            "description": "The stored fact.",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "results"
+  ],
+  "type": "object"
+}
  4. 3 tool updatesv1.0.0
    • First observedmemorysync_add
    • First observedmemorysync_read_docs
    • First observedmemorysync_search
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.6/5.0

Scored across 7 tools

Disambiguation5/5

Each tool targets a distinct operation: id-based fetch, graph traversal, decision conflict search, deletion, addition, docs lookup, and relevance search. Descriptions explicitly contrast the overlapping retrieval tools (search vs related vs decisions), leaving no ambiguity.

Naming Consistency4/5

All tools share the memorysync_ prefix and use snake_case, but verbs and nouns are mixed: get, add, forget, search, and read_docs are verb-led, while related and decisions are noun-led. This is a minor deviation from a fully consistent verb_noun pattern.

Tool Count5/5

Seven tools is a well-scoped set for a memory server, covering creation, retrieval by id, search, related-fact traversal, decision conflict detection, deletion, and self-documentation. No tools feel redundant and none are missing from the core set.

Completeness4/5

The surface covers create, read (multiple modes), and delete, plus graph and decision-specific retrieval. The notable gap is a dedicated update tool, though the documented workflow of forget-then-add mitigates it.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • ContextFS

    contextfs
    A
    license
    Not graded
    quality
    C
    maintenance
    Universal AI memory layer that provides cross-client, cross-repo context management with semantic search, automatic code indexing, and session management. Enables persistent developer memory across projects with typed memories, graph-based relationships, and RAG-powered retrieval.
    5
    MIT

  • remembrallmcp

    roboticforce
    A
    license
    Not graded
    quality
    A
    maintenance
    Persistent knowledge memory layer for AI agents. Hybrid semantic + full-text search with pgvector, code dependency graph with blast-radius impact analysis, and incremental indexing for 7 languages. In-process ONNX embeddings, no external API required.
    24 npm
    35
    MIT