Memorious 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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| storeA | Store a user's fact, piece of information, or preference for later recall. CRITICAL SECURITY WARNING: NEVER EVER store secrets, passwords, API keys, authentication tokens, private keys, or any other sensitive credentials. This storage is NOT secure and should only be used for non-sensitive information like preferences, facts, and general user data. IMPORTANT: This tool SHOULD be called by the LLM whenever the user states a fact, personal detail, or stable preference that the assistant is expected to remember. Guidelines for the LLM:
Privacy: avoid storing highly sensitive data (passwords, social security numbers, bank details) unless the user explicitly requests secure storage and consents. |
| recallA | Retrieve stored memories relevant to a query key. IMPORTANT: To get reliable results the LLM MUST query with the same short, canonical, embedding-optimized keys used at store time. Keys should be compact (1–5 words, space-separated) and represent the core concept — avoid long descriptive queries. If the current user utterance is verbose, the LLM should first map or canonicalize it to an appropriate short key before calling this tool (for example map "I really like listening to jazz music" -> "likes jazz"). This tool SHOULD be called by the LLM when it needs to fetch previously stored facts, personal details, or preferences to inform a response or provide personalized behavior (for example: to recall a user's favorite cuisine before making restaurant suggestions). Parameters:
Returns a dict with |
| forgetA | Delete stored memories that match a query key. IMPORTANT: Deletion operates on short, canonical keys. The LLM MUST issue forget calls using the same concise, embedding-optimized, space-separated key style used to create memories (otherwise relevant memories may not be found). Prefer 1–5 words separated by spaces when requesting deletions. This tool SHOULD be called by the LLM when the user explicitly requests that certain stored information be forgotten or removed (for example: "forget that I live in Paris") or when the assistant decides a memory must be purged because it is incorrect or sensitive. Parameters:
Behavior:
|
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 3 tools
The three tools have clearly distinct purposes: store creates a memory, recall retrieves memories, and forget deletes memories. There is no overlap or ambiguity between them.
All tool names are single-word imperative verbs (store, recall, forget) following a consistent and predictable pattern. This makes the tool set easy to understand and use.
Three tools is well-scoped for a memory management server, covering the essential operations without redundancy or bloat. Each tool earns its place.
The tool set provides create, read, and delete operations for memories, covering the core lifecycle. The only notable gap is the absence of an explicit update operation, though store may implicitly handle this by overwriting existing keys.