Projectmem
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROJECTMEM_ROOT | No | Absolute path to the project root (alternative to --root argument) |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_instructionsA | Read the project's mandatory AI instructions. |
| get_summaryA | Read the project memory summary. |
| get_project_mapA | Read PROJECT_MAP.md to understand the repo structure. |
| get_planA | Read plan.md — the project's INTENT file (ideas + plans). |
| precheck_fileA | Check a file's failure history BEFORE modifying it. |
| get_issueA | Read one specific issue's full history by ID (token-efficient). |
| search_eventsA | Plain-text search across all logged events. |
| get_scoreA | Get the project's failure-prevention score. |
| get_contextA | Generate a token-budgeted memory context block. |
| get_global_gotchasA | Query cross-project library gotchas from ~/.projectmem/global/. |
| log_issueA | Open a new issue. Returns the issue ID. |
| record_attemptA | Record a fix attempt on the current issue. |
| record_fixA | Record a confirmed fix and close an issue. |
| add_decisionA | Record an architectural or product decision permanently. |
| add_noteA | Record a gotcha, setup detail, or other durable context. |
| list_projectsA | List the projects this server can reach, and which one is active. |
| current_projectA | Show which project a call would resolve to, without writing anything. Use this before a write when several projects are in play — it answers "where would this land?" cheaply. Read-only. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
The read tools (get_summary, get_context, search_events, get_issue) all retrieve memory but are distinguished by scope and budget in their descriptions. list_projects vs current_project is a minor overlap but clearly differentiated (reachable vs resolved project). Write tools each target a distinct event type (issue/attempt/fix/decision/note).
Predominantly consistent verb_noun snake_case: get_*, list_*, search_*, record_*, add_*, precheck_*. The lone deviation is current_project, which is noun-only with no verb. Otherwise the pattern is predictable and readable.
17 tools is slightly above the typical 3-15 sweet spot, but each tool maps to a distinct memory operation (12 reads, 5 writes). The read/write split justifies the count, though it leans heavy.
Covers the full memory lifecycle: project discovery, reading summary/instructions/map/plan/context, issue logging, attempt/fix recording, decisions, and notes, plus cross-project gotchas and scoring. No update/delete tools exist, but decisions are deliberately append-only and plan edits are done by editing files directly, so gaps are minor and by design.