Skip to main content
Glama

Project Memory

project_memory

Save project notes that must survive this chat — rules, conventions, decisions, gotchas, preferences. Writes notes. Does not read source files. ALWAYS call when they say remember, save this, don't forget, write this down, keep this, my rule, our convention, I always want, last time, what did we decide, what did we save, show me what we stored, or you just learned something that will be gone when this session ends. PREFER this over hoping the next chat still has it. Chat memory dies when the session ends. This does not. One folder can hold many notes (up to 200). Each note is title + content (up to 2000 words) + type. Write the rule and the why — not a one-liner. type=decision|gotcha|goal|preference|area_fact|convention. area= the topic (auth, billing, deploy). tags= keywords that make it findable later (jwt, cookie). action=remember saves the note. action=recall searches title, body, area, and tags and returns matches[].content — read that text and use it. action=list shows recent notes (title, type, area, tags, preview of the body) so you can see what is stored. action=forget deletes by id. Pass limit up to 20 when they want more than a handful. One folder is one set of notes. Different folders never mix unless they ask (scope=all). Omit path on stdio (this folder) or pass that folder. Hosted: pass the same folder string every time. Stdio stores on their machine (/.zephex/memory). Hosted stores in their cloud account. Empty matches means nothing was saved for that query — do not invent a past note. If they ask what we saved, call list or recall. Example: project_memory({ action: "remember", title: "Auth is cookie JWT", content: "Session in httpOnly cookie; refresh on /api/auth/refresh. Do not store access tokens in localStorage.", type: "gotcha", area: "auth", tags: ["jwt","cookie"] }). Find it later: project_memory({ action: "recall", query: "auth cookies" }). See what is stored: project_memory({ action: "list", limit: 10 }).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoRequired for forget. Memory uuid.
areaNoSubsystem label (auth, billing, deploy) — included in search index for scoped recall. Max 64 chars.
pathNoFolder these notes belong to. Same string on remember, recall, and list. Stdio: optional (editor cwd). Hosted: reuse that folder string (or normalized_path from remember).
tagsNoOptional lowercase tags. Max 10.
typeNoRequired for remember. decision=chose an approach; gotcha=non-obvious bug; goal=what we are building toward; preference=user style; area_fact=fact about a subsystem; convention=naming or process rule.
limitNorecall/list cap. Default 10, max 20.
queryNoRequired for recall. Short keywords from the title or topic (e.g. auth middleware stripe).
scopeNoproject=this folder only (default). personal=notes that apply everywhere. all=every project — only when they ask to search everything.project
titleNoRequired for remember. Max 80 chars.
actionYesremember=save a note, recall=search notes and return full content, list=recent notes with preview, forget=delete by id
contentNoRequired for remember. Up to 12000 characters (~2000 words). Write the why and the trap — not a one-liner.
written_byNoWho authored this memory.agent

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed6 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"remember=save a fact, recall=keyword search, list=recent titles, forget=delete by id"New value: +"remember=save a note, recall=search notes and return full content, list=recent notes with preview, forget=delete by id"
    • changedInput schema / properties / content / description
      Previous value: -"Required for remember. Max 500 chars. Paraphrase, not file dumps."New value: +"Required for remember. Up to 12000 characters (~2000 words). Write the why and the trap — not a one-liner."
    • changedInput schema / properties / limit / default
      Previous value: -5New value: +10
    • changedInput schema / properties / limit / description
      Previous value: -"recall/list cap. Default 5, max 10."New value: +"recall/list cap. Default 10, max 20."
    • changedInput schema / properties / path / description
      Previous value: -"Project bucket — use the same absolute path on remember, recall, and list. Stdio: optional (defaults to editor cwd). Hosted: reuse normalized_path from the remember response."New value: +"Folder these notes belong to. Same string on remember, recall, and list. Stdio: optional (editor cwd). Hosted: reuse that folder string (or normalized_path from remember)."
    • changedInput schema / properties / scope / description
      Previous value: -"project=current DB, personal=~/.zephex personal, all=cross-project with warnings."New value: +"project=this folder only (default). personal=notes that apply everywhere. all=every project — only when they ask to search everything."
  2. Changed5 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"remember=save, recall=FTS5 search, list=titles, forget=delete by id"New value: +"remember=save a fact, recall=keyword search, list=recent titles, forget=delete by id"
    • changedInput schema / properties / area / description
      Previous value: -"Subsystem label for scoped recall. Max 64 chars."New value: +"Subsystem label (auth, billing, deploy) — included in search index for scoped recall. Max 64 chars."
    • changedInput schema / properties / path / description
      Previous value: -"Absolute project root. Stdio: optional (uses cwd)."New value: +"Project bucket — use the same absolute path on remember, recall, and list. Stdio: optional (defaults to editor cwd). Hosted: reuse normalized_path from the remember response."
    • changedInput schema / properties / query / description
      Previous value: -"Required for recall. FTS5 keywords."New value: +"Required for recall. Short keywords from the title or topic (e.g. auth middleware stripe)."
    • changedInput schema / properties / type / description
      Previous value: -"Required for remember."New value: +"Required for remember. decision=chose an approach; gotcha=non-obvious bug; goal=what we are building toward; preference=user style; area_fact=fact about a subsystem; convention=naming or process rule."
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations are sparse and non-destructive, but the description carries the behavioral burden well: it discloses persistent state, per-folder isolation, storage location differences (stdio vs hosted), that empty matches return nothing, and that the tool will not invent notes. It also explains that writes need sufficient detail ('not a one-liner'). It doesn't fully describe output shape, but with no output schema it provides more than enough behavior context.

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 long but every sentence earns its place: trigger phrases, action rules, storage semantics, and an example are all required to make the four action modes safe to invoke. The trigger list could have been tighter, but it's front-loaded with the core mission first (persist across session), then action-specific details.

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 12 parameters and no output schema, the description covers: all four actions, required parameters per action, storage location differences, folder isolation, note limits (200 notes; ~2000 words), tag/area semantics, scope=all behavior, and empty match behavior. The biggest gap is a more explicit note on how recall returns matches[] and that the agent must read the content text to use it, but even that is addressed in the text ('read that text and use it').

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?

The schema already covers 100% of parameters with descriptions, which sets a baseline. The description adds value beyond schema by describing required parameters per action ('id Required for forget', 'title/content Required for remember', 'query Required for recall'), gives a complete worked example, and explains how tags/area/title combine for search semantics. It might have explained more about the 'title' vs 'query' interplay, but it still exceeds what the structured schema provides.

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 a specific verb+resource: 'Save project notes that must survive this chat.' It explains what the tool is for, explicitly states what it does NOT do ('Does not read source files'), and outlines the four actions (remember, recall, list, forget) that map to concrete behaviors. It clearly distinguishes itself from sibling file-reading/repo tools by focusing on persisted conversational memory.

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 trigger phrases ('remember, save this, don't forget...'), states when to prefer this tool over default chat memory, and specifies which action to use in each scenario ('If they ask what we saved, call list or recall'). It also provides guidance on scope, folder isolation, and when to include limit. This is among the most actionable usage guidance possible.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct domain: URL auditing, package checking, tests, architecture, code search, project context, planning, memory, code reading, and expert guides. Descriptions are extremely detailed and explicitly state when not to use each tool, leaving no ambiguity.

Naming Consistency4/5

Most tools follow the verb_noun snake_case pattern (audit_headers, check_package, check_test, explain_architecture, find_code, get_project_context, read_code), but project_memory (noun_noun) and Zephex_dev_info (brand_noun) deviate, and keep_thinking uses a gerund instead of a noun. The pattern is strong but not perfectly uniform.

Tool Count5/5

10 tools is well-scoped for a comprehensive development assistant. Each tool serves a clear purpose without redundancy, covering security, package management, testing, code understanding, project context, planning, memory, and expert knowledge. The count is neither too few nor excessive.

Completeness4/5

The tool surface covers a wide range of development analysis tasks: security auditing, package checking, test running, architecture mapping, code search, project context, planning, memory, code reading, and developer guides. Minor gaps include the lack of direct code editing or project execution/build tools, but the server appears intentionally focused on read-only information and planning.

Resources