Skip to main content
Glama
Sign In
Memory MCP

Memory MCP

by mrunmayeekokitkar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

remember

Store a single durable fact about the user or project so AI clients can recall key preferences, decisions, and constraints in future sessions.

Instructions

Store ONE durable fact about the user or project for future recall.

When to use this tool

Use remember when you identify 1 to 3 clear, distinct facts during a conversation — a preference, a tech-stack choice, an architectural decision, an identity detail, a constraint, a workflow step, or a domain term.

Call it in real time as the conversation progresses. You do NOT need to wait for the user to explicitly ask you to save something. If the user confirms a plan you proposed (e.g. "ok, let's go with that"), save the key decisions from your proposal immediately.

When NOT to use this tool

If you just generated (or the user pasted) a dense block of text containing many facts (architecture docs, meeting notes, large plans), use ingest_conversation instead — it extracts and deduplicates automatically. Rule of thumb: if you would need more than ~3 remember calls, prefer ingest.

What to save (not just tech stack!)

Save ALL categories of durable knowledge:

  • Identity: user name, role, company, team

  • Stack: language, framework, database, cache, cloud, editor, CI/CD

  • Architecture: project purpose, system design, deployment target

  • Modules: component names, responsibilities, boundaries, dependencies

  • Workflows: CI/CD pipelines, data flows, deployment steps

  • Decisions: architectural choices and the reasoning behind them

  • Domain terms: project-specific jargon and definitions

  • Status: current milestones, blockers, known tech debt

How to write a good fact

Write a concise, third-person, present-tense, self-contained sentence. Good: "Project uses PostgreSQL as primary database." Bad: "they said postgres" (not self-contained, ambiguous)

How to resolve the project_name (Session Locking & Ambiguity)

  • No Ambiguity (IDE/Filesystem): If you can reliably determine the project from the workspace folder name or Git remote, auto-match and use it silently.

  • Ambiguity (Chat Client / Multiple Projects): On the first ambiguous remember or recall call, DO NOT GUESS. Call list_projects() and explicitly ask the user to choose (e.g., "I found these existing projects... Which one are we working on today?").

  • Session Lock: Once the user selects a project, or it is auto-matched, lock that project_name for all subsequent calls in the current session.

  • New Project: When saving to a new project name for the first time, explicitly confirm it with the user (e.g., "I've created a new project memory space called X. All facts from this session will be saved under this project.").

Args: content: The fact, e.g. "Project uses PostgreSQL as primary database." project_name: Project name to associate this fact with. If omitted (None), the fact is stored as a global memory visible to all projects. If provided, the fact is scoped to that project but still visible alongside global memories when querying that project. importance: 0..1 estimate of long-term value. - 0.85–0.95: identity, architecture, core decisions - 0.75–0.85: module descriptions, workflows - 0.70–0.80: stack choices - 0.65–0.80: domain terms, status - 0.50–0.65: preferences, dislikes - 0.40–0.50: ephemeral observations key: Optional conflict slot (e.g. "user:database"). A new fact with the same key supersedes the old one, so beliefs stay current. Common keys: user:name, user:language, user:framework, user:database, user:cloud, user:editor, user:current_project, project:architecture, project:deployment, project:purpose, project:status. For modules/workflows/decisions use dynamic keys like project:module:, project:workflow:, project:decision:. tags: Optional labels for filtering. ttl_days: Optional expiry in days for facts that go stale on their own. tool: Name of the calling tool (recorded for audit).

Returns a summary including the resulting action: created, merged (a duplicate already existed), superseded (an older conflicting fact was retired), or blocked (PII policy refused it).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "content": "<content>"
    },
    "name": "remember"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyNo
tagsNo
toolNounknown
contentYes
ttl_daysNo
importanceNo
project_nameNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses key-based supersession ('a new fact with the same key supersedes the old one'), duplicate handling (merged), PII refusal (blocked), TTL-based expiry, global vs project visibility semantics, and the session-locking / new-project confirmation requirements. These are non-obvious side effects an agent could not infer from the schema.

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?

It is well front-loaded with markdown headers and scannable sections, and the length is largely justified by seven undocumented parameters. However, the 'What to save' category list substantially duplicates the categories already enumerated in the importance rubric, and 'How to write a good fact' could be a single line without the example pair.

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 seven-parameter mutation tool with no annotations, the description covers selection criteria, param semantics, side effects, disambiguation workflow, and outcome states; the output schema handles return shape, and the description still adds the meaningful action vocabulary (created/merged/superseded/blocked). Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is 0% and the schema provides only bare titles, so the description must compensate entirely, and it does: content (with a good/bad example), project_name (None = global, otherwise project-scoped but visible alongside global), importance (a full 0.40–0.95 rubric mapped to fact categories), key (conflict-slot semantics plus a list of common and dynamic key patterns), tags, ttl_days, and tool (audit).

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 opening line gives a specific verb (store), resource (durable fact), scope (ONE, about user or project) and downstream purpose (future recall). It is immediately distinguishable from ingest_conversation (bulk extraction) and recall (retrieval) through the explicit routing sections.

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?

There is an explicit 'When to use' section with quantitative triggers (1 to 3 distinct facts), an explicit 'When NOT to use' section naming the alternative (ingest_conversation) and a decision rule ('if you would need more than ~3 remember calls, prefer ingest'). It also specifies timing (call in real time, no explicit user request needed) and the project_name disambiguation flow that routes to list_projects.

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