Skip to main content
Glama
Chaerulcp

shared-agent-memory-mcp

by Chaerulcp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

memory_search

Search shared long-term memory stored in Notion to reuse saved preferences, conventions, and past decisions. Filter by agent, category, tag, or project, and get matching memories with excerpts.

Instructions

Search the shared long-term memory stored in Notion (used by Cline, OpenCode, Claude Code, GitHub Copilot, Hermes). Returns matching memories with id, title, content, agent, category, tags. Semantic and hybrid vector matches also include match.excerpt with Unicode start/end offsets. Set response to compact to omit full content and return an excerpt; use memory_get for full content. USE THIS at the start of a task with relevant keywords, and before making decisions, to reuse saved preferences, conventions, and past decisions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNoExact tag name to filter by
modeNoSemantic and hybrid modes require a fresh local cachekeyword
agentNoOnly memories saved by this agent
limitNo
queryYesSearch text; semantic and hybrid modes also match related meaning
projectNoOnly memories for this project/repository
categoryNo
responseNoCompact omits full content; full preserves the existing responsefull
currentProjectNoUse the current Git repository as project scope when project is omitted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.6.0
    • addedInput schema / properties / currentProject
      Added value: +{
+  "default": false,
+  "description": "Use the current Git repository as project scope when project is omitted",
+  "type": "boolean"
+}
    • addedInput schema / properties / mode
      Added value: +{
+  "default": "keyword",
+  "description": "Semantic and hybrid modes require a fresh local cache",
+  "enum": [
+    "keyword",
+    "semantic",
+    "hybrid"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / project
      Added value: +{
+  "description": "Only memories for this project/repository",
+  "maxLength": 120,
+  "type": "string"
+}
    • changedInput schema / properties / query / description
      Previous value: -"Keywords/phrase to match in title, content, and tags"New value: +"Search text; semantic and hybrid modes also match related meaning"
    • addedInput schema / properties / response
      Added value: +{
+  "default": "full",
+  "description": "Compact omits full content; full preserves the existing response",
+  "enum": [
+    "full",
+    "compact"
+  ],
+  "type": "string"
+}
  2. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses return format, the presence of match.excerpt with Unicode offsets for semantic/hybrid modes, and the behavior of the response parameter. It does not mention side effects (though search implies read-only) or authentication/rate limits, but it covers the essential behavioral traits for correct invocation.

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

Conciseness4/5

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

The description is concise, front-loaded with purpose, and flows logically from what it returns to usage guidance. It avoids redundancy with the schema. It could be slightly more structured with separate sections, but it remains efficient and easy to parse.

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

Completeness4/5

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

For a tool with 9 parameters, multiple modes, and alternatives, the description covers the key behavioral aspects: return contents, compact vs full, and when to use. It does not delve into parameter interactions (e.g., currentProject vs project), but the schema covers those. Given the output schema is absent and annotations are missing, the description adequately covers what an agent needs to call it correctly.

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 high (78%), so most parameters are already documented. The description adds value by clarifying the response parameter's purpose ('compact to omit full content') and referencing the mode requirement ('require a fresh local cache'), but these are also in the schema. The baseline of 3 applies because the schema does most of the work.

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 clearly states the verb (search), the resource (shared long-term memory in Notion), and the exact return fields (id, title, content, agent, category, tags). It also distinguishes itself from siblings by noting that memory_get provides full content, making it unambiguous what this tool does.

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

Usage Guidelines4/5

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

The description explicitly instructs to use this tool at the start of a task and before decisions, with relevant keywords. It also references an alternative (memory_get) for full content. However, it does not explicitly state when not to use it relative to memory_recent or memory_delete, so it stops short of a full 5.

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