Preference Memory MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PREFERENCE_MEMORY_DB | No | Complete database path. | Platform user-data directory |
| PREFERENCE_MEMORY_DATA_DIR | No | Parent directory used when the database path is not set. | Platform user-data directory |
| PREFERENCE_MEMORY_SAMPLING | No | Sampling policy: auto, extraction-only, rerank-only, or never. | auto |
| PREFERENCE_MEMORY_RECALL_LIMIT | No | Default recall result limit; accepted range 1–50. | 12 |
| PREFERENCE_MEMORY_MAX_CANDIDATES | No | Sampling candidate limit; accepted range 1–5. | 5 |
| PREFERENCE_MEMORY_RERANK_CANDIDATES | No | Maximum semantic candidate-pool size; accepted range 1–50. | 24 |
| PREFERENCE_MEMORY_MAX_STATEMENT_CHARS | No | Stored statement limit; accepted range 3–1,200 and applied to direct and sampled candidates. | 1200 |
| PREFERENCE_MEMORY_MAX_OBSERVATION_CHARS | No | Observation limit before sampling; accepted range 1–50,000. | 8000 |
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 |
|---|---|
| memory_recallC | Recall active memories that match the current request and opaque scope selectors. |
| memory_observeC | Use host sampling to extract pending candidates without storing the raw observation. |
| memory_rememberC | Create a pending, structured memory proposal without invoking sampling. |
| memory_reviewA | List reviewable memories with cursor-based pagination. |
| memory_getA | Read one memory by its opaque identifier. |
| memory_resolveB | Approve, reject, or dispute a memory after a real form-elicitation response. |
| memory_forget | Purge one memory from live storage after form elicitation confirmation. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| memory_workflow | Describe a safe recall, proposal, review, and feedback workflow. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| profile_summary | Return active global memories without exposing scoped records. |
| pending_review | Return pending memory summaries as JSON. |
TDQS
Scored across 6 tools
Each tool targets a distinct action: reading by ID, observing candidates, recalling active memories, creating pending proposals, resolving them, and listing reviewable ones. No overlap.
All tools follow the 'memory_<verb>' pattern with clear, descriptive verbs (get, observe, recall, remember, resolve, review), ensuring predictability.
With 6 tools, the surface is well-scoped for a memory management server, covering core operations without being overly large or sparse.
The tools cover create, read, list, and resolve workflows. However, there is no explicit delete tool; while resolve may handle disposal, this omission is a minor gap for full CRUD coverage.