MCP Memory Tracker
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENAI_API_KEY | Yes | Your OpenAI API key for accessing vector stores |
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| save_memoryC | Save a memory to the vector store. |
| search_memoriesC | Search the vector store for memories that match the query. |
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 2 tools
The two tools have clearly distinct purposes: one saves memories and the other searches memories. There is no overlap or ambiguity between these operations, making it easy for an agent to select the correct tool based on the intended action.
Both tools follow a consistent verb_noun pattern (save_memory, search_memories) with clear, descriptive verbs. The naming is uniform and predictable, adhering to snake_case throughout without any deviations.
With only two tools, the server feels thin for a memory tracker domain. While save and search are core operations, typical memory systems might also include update, delete, list, or clear functions. The count is too low for comprehensive coverage, limiting agent capabilities.
The tool surface is significantly incomplete for a memory tracker. It lacks essential operations like updating or deleting memories, listing all memories, or managing memory categories. This creates dead ends for agents trying to perform full lifecycle management of memories.