project-memory-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsA | List all projects under ~/code that have an AGENTS.md memory file. |
| get_projectB | Return the full AGENTS.md memory for one project. |
| search_memoryA | Case-insensitive search across every project's AGENTS.md. Returns matching lines with their project. |
| append_decisionA | Append a dated bullet under '## Decisions' in a project's AGENTS.md (auto-loaded memory). Call this PROACTIVELY right after a non-obvious or architectural decision is made — don't wait to be asked — then tell the user in one line what you recorded. For concise, durable decisions and WHY; not bugs (use log_issue) and not trivia. |
| append_learningA | Append a dated bullet under '## Learnings' in a project's AGENTS.md (auto-loaded memory). Call this PROACTIVELY when you discover a durable gotcha/workaround future sessions should know — don't wait to be asked — then tell the user what you recorded. For a specific bug use log_issue instead. |
| remember_preferenceA | Append a dated bullet under '## Preferences' in an AGENTS.md (auto-loaded memory), turning a user correction or stated habit into a remembered pattern that comes back next session. Call this PROACTIVELY when the user corrects HOW you work or states a durable preference — code style, workflow habit, a 'from now on' rule (e.g. 'never add a co-author trailer', 'always run the typecheck before committing') — don't wait to be asked, then tell the user in one line what you saved. Use scope 'global' (root AGENTS.md, applies to EVERY project) for a cross-project habit; scope 'project' for a preference about one project. This is about agent behaviour/preferences; for a project DECISION use append_decision, for a bug use log_issue. |
| log_issueA | Append a structured bug/issue to /issues.jsonl (high-volume memory, NOT auto-loaded). Call this PROACTIVELY whenever you resolve (or get blocked by) a non-trivial bug — don't wait to be asked — then tell the user in one line what you logged. Skip trivial/transient issues. |
| search_issuesA | Search bug/issue history across all projects (or one) over the TEXT FIELDS only (symptom, cause, fix, id, tags) — not the raw JSON, so you won't get false hits on field names like 'fix' or 'status'. Optionally filter by tags (issue must carry all of them). Either query or tags may be given. Call this PROACTIVELY when the user reports an error or you hit a familiar-looking failure, BEFORE debugging from scratch, to check for a prior fix ('have we hit this before?'). |
| list_open_issuesB | List unresolved issues across all projects (or one). |
| resolve_issueB | Mark an issue resolved and record the fix. |
| start_initiativeA | Start tracking a named, multi-session effort under a codename — a plan plus an evolving todo list stored in /initiatives/.md, with a pointer kept in the project's auto-loaded AGENTS.md under '## Active Initiatives' so a BRAND NEW session sees it's in flight without calling any tool. Call this PROACTIVELY when the user names a multi-step effort with a codename or asks you to 'track this as X' / 'remember this under the name X' — don't wait to be asked. If the codename already exists, returns the existing initiative unchanged (safe to call again on a resumed session) rather than overwriting progress. |
| get_initiativeA | Fetch the full plan/todos/progress log for one named initiative by codename (case/spacing-insensitive — 'hash gate' matches 'HashGate'). Call this PROACTIVELY at the start of a session when the user references resuming a specific named effort. If the codename doesn't resolve, lists that project's known initiatives instead of erroring blindly. |
| list_initiativesA | List named initiatives (codename, status, last updated) across one project or — if project is omitted — ALL projects, most-recently-updated first. Call this PROACTIVELY when the user references resuming past work ('continue X', 'where were we on Y') WITHOUT stating an exact codename or which project, instead of guessing or searching blindly. |
| update_initiativeA | Update a named initiative: append a dated progress-log line, add new todos, check off completed todos (matched by case-insensitive substring against existing unchecked items), and/or change status. Call this PROACTIVELY as todos complete or real progress happens — not just at session end — then tell the user in one line what you recorded. Setting status to 'done' removes its pointer from AGENTS.md's Active Initiatives (the file itself is kept as history, still reachable via get_initiative/list_initiatives). |
| sync_registryA | Reconcile the root AGENTS.md projects table with what's actually on disk: list projects that have an AGENTS.md but no table row (and add a stub row for each), flag rows whose directory no longer exists, and show live open-issue counts. Automates the 'new project → add a row' step so the cross-project index never silently drifts. Hand-curated columns (Stack, Status, descriptions) are preserved — stubs use the project's '## What this is' line and leave Stack/Status as '?'. Set apply=false to report drift without writing. |
| find_by_fileA | Given a file path or filename fragment, return the issues (matched via their 'files' field) and the decisions/learnings (matched via AGENTS.md bullets that mention it) that touch that file — i.e. 'why is this code the way it is?' answered from memory. Searches all projects unless one is given. Useful when you land on confusing code and want the history behind it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kaaustubh/project-memory-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server