Product Memory
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_project_overviewB | Product purpose, service map, boundaries, and critical rules for a project/repository. Call when entering a repo for the first time. |
| get_task_contextA | Compact task-specific packet: architecture, business rules, gotchas, code pointers, risks, verification steps. Call BEFORE planning. |
| search_product_memoryA | Ranked search over all verified product/architecture/incident memory. Returns a SNIPPET of each hit — the passage that matched — plus |
| read_memoryA | The FULL body of one memory, by the The counterpart to snippet results: search gives you the passage that matched and enough to choose from, this gives you the whole note once you have chosen. Returns None when the id is unknown, which is the honest answer for a stale id from an older session rather than a guess at the nearest match. |
| get_domain_rulesA | Verified invariants for a domain operation (e.g. 'wallet' / 'reverse transaction'). MANDATORY before money-path/auth/tenancy changes. |
| get_related_decisionsC | ADRs and past decisions relevant to a task or the paths it touches. |
| why_codeA | WHAT/WHY/WHY-THIS-WAY/GOTCHA card for a function or file. Call before rewriting existing code so past decisions aren't undone blindly. |
| get_recent_workC | Worklog: what was done and why, newest first. since = ISO date. |
| propose_memoryA | Record a new memory. Auto-approved by default; set Auto-approve is the default because a proposal sitting in the inbox is a fact
the next session does not have — the queue was the thing between writing a
memory and being able to use it. Redaction and collision-safety are NOT
relaxed by it: secrets are still stripped before the write (the store is
committed to git) and an id clash still suffixes rather than overwrites.
Auto-approved entries record Use at task completion: one type='code_symbol' entry per function you added
or meaningfully changed (body: WHAT: / WHY: / NEED: / WHY THIS WAY: /
GOTCHA:), passing Never include credentials, tokens, or passwords — this store is committed to git. |
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 9 tools
The tools have mostly clear, distinct purposes: search vs. read, context retrieval vs. rule retrieval, and write vs. read. However, the context-retrieval tools (get_project_overview, get_task_context, get_domain_rules, get_related_decisions) overlap somewhat and rely on descriptions to tell them apart, and search_product_memory with full=True partially duplicates read_memory.
Most tools follow a consistent get_/search_/read_/propose_ verb pattern, which makes the set predictable. why_code breaks the pattern as a noun-style tool name, and the mix of get_ with search_/read_ is a minor deviation.
Nine tools is well within the ideal range for a product memory server, and each tool covers a distinct retrieval or write need. The count feels appropriately scoped without being bloated or thin.
The surface covers the core lifecycle well: search, read, targeted context retrieval, recent work, and recording new memories. There is no explicit update/delete/invalidation tool for memories, though the append-only/id-suffix design suggests this may be intentional; still, explicit correction would make it more complete.