Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@memory-mcp save my project idea for a chat bot"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Personal memory MCP server for Claude Code with an Obsidian-style interactive graph.
Persistent, queryable memory across Claude Code sessions. Memories are plain Markdown files with YAML frontmatter. Wiki-links ([[Memory Name]]) create bidirectional connections visualized in a D3.js force-directed graph at localhost:4242.
(graph UI screenshot here)
Related MCP server: memcp
8 MCP tools — save, read, search, list, delete, graph data, stats, open graph
D3.js force-directed graph — Obsidian-style visual graph of all memories and their connections
Wiki-links — [[Memory Name]] in content auto-creates bidirectional links
Fuzzy search — powered by Fuse.js, searches name, content, and tags
5 memory types — each rendered as a distinct color in the graph
Plain Markdown storage — memories are .md files with YAML frontmatter, readable without any tooling
Web UI at localhost:4242 — search, type filters, node click opens a sidebar with rendered Markdown
96% test coverage — Vitest, isolated per module with temp vault directories
git clone https://github.com/otaviosenne/memory-mcp
cd memory-mcp
npm install
npm run buildAdd to Claude Code's ~/.claude/mcp.json:
{
"mcpServers": {
"memory-mcp": {
"type": "stdio",
"command": "node",
"args": ["/path/to/memory-mcp/dist/index.js"],
"env": {
"MEMORY_VAULT_PATH": "~/.local/share/memory-mcp/vault",
"MEMORY_WEB_PORT": "4242"
}
}
}
}Restart Claude Code. The MCP server starts automatically with the session.
Tool | Description |
| Create or update a memory by name |
| Read a single memory by ID or name |
| Fuzzy search across name, content, and tags |
| List all memories, optionally filtered by type |
| Delete a memory by ID |
| Return all nodes and edges for graph rendering |
| Count memories by type, total links, vault size |
| Open the web UI in the default browser |
memory_saveInput:
{
"name": "Chrome Agent MCP",
"type": "project",
"content": "Browser automation MCP using Chrome DevTools Protocol. Built on [[memory-mcp]] for session context.",
"tags": ["mcp", "typescript", "chrome"]
}Output:
{
"id": "a1b2c3d4-...",
"name": "Chrome Agent MCP",
"type": "project",
"links": ["<uuid-of-memory-mcp>"],
"created": "2026-03-24T10:00:00.000Z"
}memory_searchInput:
{ "query": "typescript mcp" }Output: array of matching memories, sorted by relevance score.
memory_statsOutput:
{
"total": 24,
"byType": { "project": 10, "user": 5, "feedback": 4, "reference": 3, "note": 2 },
"totalLinks": 38
}Type | Graph Color | When to Use |
| Green | Personal info, preferences, skills, background |
| Blue | Project decisions, tech stack, current status, constraints |
| Yellow | Corrections and confirmed patterns ("don't do X", "yes, exactly like this") |
| Pink | External resources, accounts, tools, links |
| Gray | General context that doesn't fit other types |
Use [[Memory Name]] syntax anywhere in a memory's content to reference another memory by exact name.
This project depends on [[memory-mcp]] for persistent context across sessions.
The architecture follows the patterns described in [[SOLID Design Principles]].Links are resolved at save time. Both the source and target memory store the connection — the graph is always bidirectional. If the target memory does not exist yet, the link is stored as unresolved and re-evaluated when the target is created.
Open localhost:4242 while the MCP server is running (or call memory_open_graph).
Node size scales with connection count — highly-linked memories appear larger
Node color maps to memory type
Click a node to open a sidebar with the full Markdown content, rendered
Search bar filters nodes by name or tag in real time
Type toggles show or hide entire memory types
Zoom and pan are supported via D3 zoom behavior
The graph updates live — refresh the page to reflect new memories.
/save-memoriesAt the end of a session, run /save-memories to extract and persist meaningful context automatically.
The skill reviews the conversation and decides what is worth saving. It skips trivial fixes and ephemeral tasks — it only saves things that would be genuinely useful in a future session.
~/.claude/skills/save-memories/SKILL.md:
---
name: save-memories
description: Analyze the current conversation and save meaningful memories to the personal memory vault. Use at the end of any session where something worth remembering was discussed — new projects, preferences revealed, corrections made, important context.
user-invocable: true
---
# Save Memories
Analyze the current conversation and save relevant memories to the vault at `/home/senne/.local/share/memory-mcp/vault/`.
## Step 1 — Review the conversation
Read back through what was discussed. Ask: what here would be useful to know in a future conversation that isn't already obvious from the code?
## Step 2 — Decide what to save
Only save if it reveals:
| Type | Save when |
|------|-----------|
| `user` | Personal info, skills, preferences, opinions, background |
| `feedback` | Corrections ("not like that"), confirmed patterns ("yes, exactly") |
| `project` | Project decisions, stack, current status, key constraints |
| `reference` | External resources, accounts, tools, links, credentials context |
| `note` | Important context that doesn't fit other types |
**Skip:** trivial bug fixes, ephemeral tasks, things obvious from the code, duplicates.
## Step 3 — Save each memory
For each memory, run:
```bash
node -e "
import('/path/to/memory-mcp/dist/core/vault.js').then(async ({ Vault }) => {
const vault = new Vault('/path/to/vault');
await vault.initialize();
const saved = await vault.save({
name: 'MEMORY NAME',
type: 'project',
content: 'Content here. Use [[Other Memory Name]] to link related memories.',
tags: ['tag1', 'tag2'],
});
console.log('Saved:', saved.name, '| links:', saved.links.length);
process.exit(0);
});
" 2>/dev/nullUse [[wiki-links]] in content to connect related memories. The exact name must match an existing memory name.
After saving, briefly list what was saved and why. Keep it to one line per memory.
---
## Architecture
src/ ├── index.ts # MCP server entry point, tool registration ├── types/index.ts # All TypeScript types and interfaces ├── core/ │ ├── storage.ts # File I/O abstraction (read, write, delete, list) │ ├── parser.ts # Frontmatter parsing and serialization (gray-matter) │ ├── linker.ts # Wiki-link extraction and bidirectional resolution │ └── vault.ts # Orchestrator: CRUD, search, graph, stats ├── tools/ # 8 MCP tool handlers, one file per tool └── web/ ├── server.ts # Express REST API serving graph data └── public/index.html # D3.js graph UI, single-file, no build step
Each module has one responsibility. The `Vault` class composes `Storage`, `Parser`, and `Linker` — it does not implement any of their logic directly.
---
## Tech Stack
| Package | Role |
|---------|------|
| `@modelcontextprotocol/sdk` | MCP server protocol |
| `d3` v7 | Force-directed graph in the browser |
| `express` | REST API for the web UI |
| `gray-matter` | YAML frontmatter parsing |
| `fuse.js` | Fuzzy search |
| `zod` | Tool input validation |
| `vitest` | Tests (96% coverage) |
| TypeScript strict mode | Type safety throughout |
---
## Code Patterns & SOLID
The codebase applies SOLID principles throughout:
**Single Responsibility** — each module does exactly one thing. `Storage` handles file I/O. `Parser` handles Markdown/frontmatter. `Linker` handles wiki-link extraction and resolution. `Vault` orchestrates them.
**Open/Closed** — new memory types can be added by extending the `MemoryType` union in `types/index.ts`. No core logic changes.
**Dependency Inversion** — `Vault` depends on the `Storage` and `Parser` interfaces, not their concrete implementations. This makes the core fully testable with mock implementations.
**Small files** — every file stays under 100 lines. No file mixes concerns.
No comments in the source — names are the documentation. No magic numbers — all constants are named. All code is in English.
---
## Testing
```bash
npm test # run all tests
npm run test:coverage # coverage report (target: 70%+, actual: 96%)Tests live in tests/, mirroring src/:
tests/
├── core/
│ ├── storage.test.ts
│ ├── parser.test.ts
│ ├── linker.test.ts
│ └── vault.test.ts
└── tools/
└── *.test.tsEach test suite creates a temporary vault directory and tears it down after. No shared state between tests.
Variable | Default | Description |
|
| Directory where memory |
|
| Port for the graph web UI |
Each memory is stored as a .md file with YAML frontmatter:
---
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
name: Chrome Agent MCP
type: project
tags:
- mcp
- typescript
- chrome
created: 2026-03-24T10:00:00.000Z
updated: 2026-03-24T10:00:00.000Z
links:
- b2c3d4e5-f6a7-8901-bcde-f12345678901
---
Browser automation MCP using Chrome DevTools Protocol.
Built on [[memory-mcp]] for persistent session context.
Supports screenshot, click, fill, scroll, and JS evaluation.Files are human-readable and can be edited directly. The links array is managed automatically by the linker — manual edits to links are valid but wiki-links in content take precedence on next save.
MIT
Delete a memory by ID, name, or slug
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does not state whether deletion is permanent, whether it cascades, or whether any confirmation is required. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's function without any superfluous words. It is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple one-parameter tool and covers the essential action. However, it lacks behavioral details such as return values, effects on related data, or error conditions. Given that there is no output schema or annotations, the description feels incomplete for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required 'query' string with no description. The description adds semantic meaning by explaining that query can be an ID, name, or slug, making the parameter's purpose clear. This compensates for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete a memory by ID, name, or slug', using a specific verb and resource. This clearly distinguishes it from sibling tools like memory_save and memory_read, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. Usage is only implied by the delete action; there is no mention of when deletion is appropriate or when another tool like memory_update should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get graph data (nodes and edges)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only indicates a get operation, but does not disclose whether it's read-only, expensive, returns the entire graph, or any other behavioral traits. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. However, it could be slightly more informative without losing conciseness, such as mentioning what format the data is in.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no params, no output schema), the description covers the basic purpose. But it lacks contextual completeness regarding how this differs from 'memory_open_graph' and what the returned graph data looks like, leaving a gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description correctly implies no parameters are needed, and the schema confirms 100% coverage. No further parameter explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('graph data'), and clarifies the content as 'nodes and edges'. This clearly states what the tool does, though it doesn't explicitly differentiate it from the sibling 'memory_open_graph'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'memory_open_graph' or 'memory_read'. The description simply states what it does without any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List memories with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| tags | No | ||
| type | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden of behavioral disclosure. It conveys a read-only operation via 'List' but omits details about return format, pagination, defaults, or any side effects. This is minimal information for a tool with no other metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with no fluff. It places the core action upfront. However, it is so brief that it borders on under-specification, though conciseness itself is achieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a listing tool with 4 optional parameters. There is no output schema, no annotations, and the description does not cover return values, default limits, or ordering behavior. The schema provides some enums, but the overall context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It only says 'optional filters,' which is already evident from the schema's non-required fields. It does not explain the meaning or usage of 'sort,' 'tags,' 'type,' or 'limit,' adding no real value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('List') and resource ('memories'), and mentions optional filters. However, it does not differentiate from sibling tools like memory_search or memory_read, which also deal with retrieving memory data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not specify prerequisites, scenarios, or exclusions, leaving the agent without context for choosing memory_list over memory_search or memory_read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the graph UI in browser
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the primary action (opening a browser UI) but does not mention possible side effects, whether it is a safe read-only operation, or if any external dependencies (e.g., a running server) are required. This leaves some ambiguity but is acceptable for a simple UI-launching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with the verb and object front-loaded. There is no wasted wording, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, no annotations, and no output schema, the description is sufficiently complete. It fully communicates the tool's purpose and behavior in its simple context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the schema already captures everything. The description does not need to explain any parameters, and the baseline for a parameterless tool is 4, which is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('open') and the target ('graph UI in browser'), making it unambiguous. It distinguishes itself from sibling memory tools like memory_save or memory_graph_data by describing a UI action rather than a data operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, such as memory_graph_data for retrieving graph data. There are no exclusions, prerequisites, or context clues for the agent to determine the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a memory by ID, name, or slug
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the operation is a read, implying non-destructive behavior, but does not disclose what happens on missing IDs, return format, or potential errors. This leaves the agent guessing about outcomes when invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant information. It efficiently conveys the tool's purpose and the meaning of its only parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations), so the description is minimally viable. However, it omits return value details and error behavior for not-found cases. Given the low complexity, a score of 3 is appropriate rather than lower.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for 'query' (0% coverage), so the description's clarification that it accepts an ID, name, or slug adds essential semantic meaning. This effectively compensates for the missing schema description, though it does not include syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'read' with the resource 'memory' and clarifies the identifier types ('by ID, name, or slug'), which clearly distinguishes it from sibling tools like memory_save, memory_search, and memory_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of use is implied: this is for reading a specific memory when you know its ID, name, or slug. However, there is no explicit guidance on when not to use it (e.g., for searching or listing) or mentions of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save or update a memory
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| tags | No | ||
| type | Yes | ||
| links | No | ||
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states the action 'Save or update' without explaining upsert semantics, idempotency, side effects, or permission requirements. This leaves significant ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. However, its brevity comes at the cost of necessary explanatory content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description needs to provide operational context. It lacks details on return values, error conditions, and behavior when memory already exists, making it incomplete for a 5-parameter write tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain any parameters. 'name', 'type', 'content', 'tags', and 'links' are left undefined, with no distinction between required and optional or the meaning of enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Save or update' with a specific resource 'memory', indicating a write operation. It distinguishes from sibling tools like memory_read, memory_search, and memory_delete by covering create/update functionality, though it doesn't explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool over alternatives, prerequisites, or scenarios where saving is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzy search memories
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| type | No | ||
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of disclosing behavioral traits. It only states 'Fuzzy search memories' and does not indicate whether the tool is read-only, whether it has side effects, whether it requires authentication, or what the result format is. The lack of behavioral detail is a significant gap for a tool that may be called by an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('Fuzzy search memories'), which keeps it concise, but this is under-specification rather than effective brevity. A useful description would at least mention essential scope or parameters without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description must provide substantial context. It fails to do so, offering only a vague one-liner. The agent has no way to understand the search semantics, filtering options, or expected return values, making the description inadequate for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining the meaning of parameters. It does not. The schema itself lists 'query', 'tags', 'type', and 'limit', but the description gives no hints about their semantics (e.g., whether 'query' is a full-text search string or a substring, how 'tags' interact with the search, or what 'type' values mean).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'search' and resource 'memories', but the term 'fuzzy' is vague and does not clarify what is searched (content, tags, metadata) or how results are ranked. It does not differentiate from sibling tools like memory_list or memory_read, which also operate on memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as memory_list or memory_read. There is no mention of typical use cases, exclusions, or recommended filters, leaving the agent to guess when a search is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get vault statistics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether this is a read-only operation, potential side effects, authentication requirements, or return format. It only says 'Get vault statistics,' leaving the agent to infer behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb 'Get' and resource. Every word earns its place, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters) but has no output schema. The description fails to clarify what 'vault statistics' actually are (e.g., count of memories, storage usage, etc.). This lack of detail leaves the agent uncertain about the tool's output, making the description incomplete for a tool with no other structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty properties). Per the baseline for 0-parameter tools, the description does not need to explain parameter semantics. The mention of 'vault statistics' adds a slight hint about what the output relates to, but no parameter-specific information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get vault statistics' uses a specific verb 'get' and resource 'vault statistics', which clearly differentiates it from sibling tools like memory_list (listing memories) or memory_search (searching). However, it does not specify what the statistics include, so it is clear but slightly vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply states what it does without providing context on use cases, prerequisites, or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: save, read, search, list, delete, graph data, stats, and open graph UI. The only slight overlap is between fuzzy search and filtered list, but their descriptions make the difference clear.
All tool names follow the consistent pattern memory_<action> using lowercase snake_case. The naming is predictable and makes the purpose of each tool immediately understandable.
With 8 tools, the set is well-scoped for a memory vault: it covers CRUD operations, search, list, graph data, stats, and a UI opener without unnecessary bloat or thinness.
The toolset provides full lifecycle coverage for memories (create/update, read, search/list, delete) and also offers graph and stats features for deeper interaction. No obvious gaps are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Personal knowledge graph as an AI memory layer over MCP - read, save, and link your memories.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/otaviosenne/memory-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
