Skip to main content
Glama
memorysyncio

MemorySync Cursor Starter

Official
by memorysyncio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Search saved project memories

memorysync_search
Read-only

Retrieve stored project facts and user preferences: architectural decisions, naming conventions, pinned dependencies. Use before answering build questions to avoid re-asking for known info.

Instructions

Retrieve facts previously saved about THIS project and user: architectural decisions, naming conventions, pinned dependency versions, and stated preferences. Call this before answering questions about how the project is built, and before re-asking the user something they may have already told you. Returns ranked matches with an id and a relevance score. This searches the user's own stored memories only - to look up how MemorySync itself works, use memorysync_read_docs instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kNoMaximum 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.
queryYesNatural 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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesNumber of memories returned.
resultsYesMatching memories, most relevant first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.2
    • 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
  2. Changed6 schema 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"
+}
  3. First observedv1.0.0

TDQS

A4.5/5.0
Behavior4/5

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

readOnlyHint and openWorldHint already establish the operation's safety and open-world nature, lowering the burden. The description adds return-shape detail ('Returns ranked matches with an id and a relevance score') and a scope restriction ('searches the user's own stored memories only'), which are behavioral facts not present in the annotations. No contradiction with annotations exists.

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 with a distinct job: what it retrieves, when to invoke it, and how results, scope, and alternatives behave. The most important scoping information is front-loaded, and there is no filler or repetition of schema content.

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?

With an output schema present and annotations covering safety/open-world, the description supplies the remaining decision-relevant context: when to call, what scope is searched, and which sibling to use for MemorySync documentation. For a two-parameter, read-only search tool, nothing needed 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 input schema already covers 100% of parameters with rich descriptions—query includes examples and phrasing advice, k includes default, max/min, and degradation guidance—so the baseline of 3 applies. The tool description does not add parameter-level detail beyond the schema; its relevance mention pertains to output, not parameter semantics.

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 opens with 'Retrieve facts previously saved about THIS project and user', which specifies a precise action and resource, and enumerates concrete memory types (architectural decisions, naming conventions, pinned dependency versions). It also draws an explicit boundary against a sibling: 'to look up how MemorySync itself works, use memorysync_read_docs instead.' This fully distinguishes the tool from its siblings.

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 direct when-to-use guidance: 'Call this before answering questions about how the project is built, and before re-asking the user something they may have already told you.' It also defines the exclusion territory by stating 'This searches the user's own stored memories only' and routes to memorysync_read_docs for the alternative case. Nothing is left to inference.

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

Deploy Server

Other Tools