MemorySync Cursor Starter

Official

by memorysyncio

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Read MemorySync product documentation

memorysync_read_docs

Read-only

Retrieve current MemorySync documentation for REST endpoints, SDK usage, and MCP configuration before writing integration code. Ensures method names and parameters come from up-to-date docs.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`topic`	Yes	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.

Output Schema

TableJSON Schema

Name	Required	Description
`url`	No	Canonical documentation URL for the topic.
`topic`	Yes	Topic that was resolved.
`content`	Yes	Documentation text as Markdown.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.0.2Sep 23, 2026

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
```

Changed3 schema fields changedSep 23, 2026

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"
+}

First observedv1.0.0Sep 23, 2026

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.

Deploy Server