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., "@Multi-Memory MCP Server Save a note in my work category that the server migration is scheduled for Friday."
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.
A multi-category knowledge graph memory server using SQLite for persistent storage. Organize memories into isolated contexts for different purposes (work, personal, projects, etc.).
Based on @modelcontextprotocol/server-memory with enhancements:
SQLite database storage with proper indexing and transactions
Multi-category support with isolated memory contexts
LRU connection cache (prevents memory leaks)
ID-based operations - all objects have unique IDs for precise operations
Dual identification - use ID or name/type composite key
Custom properties - JSON properties on entities, observations, and relations (searchable)
Override mode - update existing records instead of skipping duplicates
SQL injection protection
Full test coverage (141 tests)
The fastest way to use multi-memory-mcp is to run it directly from GitHub using npx:
npx github:DanNsk/multi-memory-mcpThis will download, build, and run the server automatically. Perfect for trying it out or using in Claude Desktop config:
{
"mcpServers": {
"multi-memory": {
"command": "npx",
"args": ["github:DanNsk/multi-memory-mcp"],
"env": {
"MEMORY_BASE_DIR": "/path/to/.memory",
"DEFAULT_CATEGORY": "default"
}
}
}
}git clone https://github.com/DanNsk/multi-memory-mcp
cd multi-memory-mcp
npm install
npm run buildAdd to Claude Desktop config:
Config file locations:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Using npx (recommended):
{
"mcpServers": {
"multi-memory": {
"command": "npx",
"args": ["github:DanNsk/multi-memory-mcp"],
"env": {
"MEMORY_BASE_DIR": "/Users/yourname/.memory",
"DEFAULT_CATEGORY": "default"
}
}
}
}Using local installation (macOS/Linux):
{
"mcpServers": {
"multi-memory": {
"command": "node",
"args": ["/absolute/path/to/multi-memory-mcp/dist/index.js"],
"env": {
"MEMORY_BASE_DIR": "/Users/yourname/.memory",
"DEFAULT_CATEGORY": "default"
}
}
}
}Using local installation (Windows):
{
"mcpServers": {
"multi-memory": {
"command": "node",
"args": ["C:\\path\\to\\multi-memory-mcp\\dist\\index.js"],
"env": {
"MEMORY_BASE_DIR": "C:\\Users\\yourname\\.memory",
"DEFAULT_CATEGORY": "default"
}
}
}
}MEMORY_BASE_DIR: Base directory for all memory categories (default: .aim in current working directory)
DEFAULT_CATEGORY: Default category when none specified (default: "default")
SERIALIZATION_FORMAT: Output format for tool responses (default: "json")
json - Standard JSON with 2-space indentation
toon - TOON (Token-Oriented Object Notation) - compact format optimized for LLMs with 30-60% fewer tokens
When SERIALIZATION_FORMAT=toon, responses use TOON format which is more token-efficient for LLM contexts.
Structure:
Objects: key: value with 2-space indentation for nesting
Arrays: name[count]{field1,field2}: followed by comma-separated rows
Primitives: unquoted unless containing special characters
Escaping rules (only these escape sequences are valid):
\\ - backslash
\" - double quote
\n - newline
\r - carriage return
\t - tab
Quoting required when: empty string, leading/trailing spaces, matches true/false/null, numeric, or contains : " \ [ ] { } ,
Example JSON vs TOON:
JSON (standard):
{
"entities": [
{"id": "1", "name": "AuthService", "entityType": "module", "observations": []}
]
}TOON (compact):
entities[1]{id,name,entityType,observations}:
1,AuthService,module,[]See TOON specification for full format details.
Related MCP server: Knowledge Graph Memory Server
Each category stores data in a separate SQLite database with the following schema:
entitiesPrimary storage for graph nodes.
Column | Type | Description |
| INTEGER PRIMARY KEY AUTOINCREMENT | Unique entity identifier |
| TEXT NOT NULL | Entity name |
| TEXT NOT NULL | Entity classification type |
| TEXT | JSON properties (searchable) |
| INTEGER | Unix timestamp of creation |
| INTEGER | Unix timestamp of last update |
Unique Constraint: (name, entity_type) - entities are identified by name+type combination
observationsFacts and notes associated with entities.
Column | Type | Description |
| INTEGER PRIMARY KEY AUTOINCREMENT | Unique observation identifier |
| INTEGER NOT NULL | Foreign key to |
| TEXT NOT NULL DEFAULT '' | Type/category of observation |
| TEXT NOT NULL | Observation text |
| TEXT | ISO 8601 timestamp |
| TEXT NOT NULL DEFAULT '' | Origin of observation |
| TEXT | JSON properties (searchable) |
| INTEGER | Unix timestamp of creation |
Foreign Key: entity_id → entities(id) ON DELETE CASCADE
Unique Constraint: (entity_id, observation_type, source) - one observation per type+source per entity
relationsDirected connections between entities.
Column | Type | Description |
| INTEGER PRIMARY KEY AUTOINCREMENT | Unique relation identifier |
| INTEGER NOT NULL | Foreign key to |
| INTEGER NOT NULL | Foreign key to |
| TEXT NOT NULL | Type of relationship |
| TEXT | JSON properties |
| INTEGER | Unix timestamp of creation |
Foreign Keys:
from_entity_id → entities(id) ON DELETE CASCADE
to_entity_id → entities(id) ON DELETE CASCADE
Unique Constraint: (from_entity_id, to_entity_id, relation_type)
idx_entities_name - Fast lookup by entity name
idx_entities_type - Fast lookup by entity type
idx_entities_name_type - Fast lookup by name+type combination
idx_observations_entity - Fast lookup of observations by entity
idx_relations_from - Fast lookup by source entity
idx_relations_to - Fast lookup by target entity
idx_relations_type - Fast lookup by relation type
┌─────────────────┐
│ entities │
├─────────────────┤
│ id (PK) │◄─────────────┬──────────────┐
│ name │ │ │
│ entity_type │ │ │
│ created_at │ │ │
│ updated_at │ │ │
└─────────────────┘ │ │
│ │
┌─────────────────┐ │ │
│ observations │ │ │
├─────────────────┤ │ │
│ id (PK) │ │ │
│ entity_id (FK) │──────────────┘ │
│ content │ (ON DELETE CASCADE) │
│ timestamp │ │
│ source │ │
│ created_at │ │
└─────────────────┘ │
│
┌─────────────────┐ │
│ relations │ │
├─────────────────┤ │
│ id (PK) │ │
│ from_entity_id │─────────────────────────────┤
│ to_entity_id │─────────────────────────────┘
│ relation_type │ (Both FK: ON DELETE CASCADE)
│ created_at │
└─────────────────┘Notes:
All IDs are auto-generated integers
Deleting an entity cascades to delete all its observations and relations
Relations store entity IDs, but API accepts name/type which is resolved to IDs
Organize memories into separate isolated databases. Each category has its own SQLite database file.
Category naming rules:
Lowercase letters, numbers, hyphens, underscores only
Cannot start with dots
Examples: work, personal, project-alpha, dependencies
Directory structure:
.memory/
├── work.db
├── personal.db
└── project-alpha.dbNodes in the knowledge graph with:
id - Unique numeric identifier (auto-generated)
name - Human-readable identifier
entityType - Classification (e.g., "module", "class", "person", "project")
observations - List of facts with metadata
{
"id": "1",
"name": "AuthService",
"entityType": "module",
"observations": [
{
"id": "1",
"observationType": "description",
"text": "Handles authentication",
"timestamp": "2025-11-19T10:30:00Z",
"source": "code-analysis"
},
{
"id": "2",
"observationType": "location",
"text": "Located in src/auth/",
"timestamp": "2025-11-19T10:31:00Z",
"source": "code-analysis"
}
]
}Directed connections between entities with their own IDs:
{
"id": "1",
"from": "APIController",
"fromType": "controller",
"to": "AuthService",
"toType": "module",
"relationType": "depends_on"
}All operations support identifying objects by either:
ID - Fast, precise, unambiguous
Name/Type - Human-friendly composite key
This allows flexibility when you have the ID (e.g., from a previous response) or need to reference by name.
All tools accept optional category parameter (defaults to DEFAULT_CATEGORY).
Create new entities in the knowledge graph.
Input:
{
"category": "work",
"override": false,
"entities": [
{
"name": "UserService",
"entityType": "service",
"properties": {
"filePath": "/src/services/user.ts",
"tags": ["core", "authentication"]
},
"observations": [
{
"observationType": "description",
"text": "Manages user data",
"timestamp": "2025-11-19T10:00:00Z",
"source": "code-analysis",
"properties": {
"confidence": 0.95,
"lineNumber": 42
}
}
]
}
]
}Notes:
entityType defaults to empty string
Observations are unique by (entity, observationType, source)
properties is optional JSON for custom metadata (searchable)
override: true replaces existing entities instead of skipping them
Output:
[
{
"id": "1",
"name": "UserService",
"entityType": "service",
"properties": {
"filePath": "/src/services/user.ts",
"tags": ["core", "authentication"]
},
"observations": [
{
"id": "1",
"observationType": "description",
"text": "Manages user data",
"timestamp": "2025-11-19T10:00:00Z",
"source": "code-analysis",
"properties": {
"confidence": 0.95,
"lineNumber": 42
}
}
]
}
]Create relationships between entities. Each endpoint can be specified by ID or name/type.
Input (using name/type):
{
"category": "work",
"override": false,
"relations": [
{
"from": {
"name": "APIController",
"type": "controller"
},
"to": {
"name": "UserService",
"type": "service"
},
"relationType": "uses",
"properties": {
"weight": 0.8,
"since": "2024-01-01"
}
}
]
}Notes:
type defaults to empty string if not provided
properties is optional JSON for custom metadata
override: true updates existing relations instead of skipping them
Input (using IDs):
{
"category": "work",
"relations": [
{
"from": { "id": "1" },
"to": { "id": "2" },
"relationType": "uses"
}
]
}Note: You can mix ID and name/type - e.g., from by ID and to by name/type.
Output:
[
{
"id": "1",
"from": "APIController",
"fromType": "controller",
"to": "UserService",
"toType": "service",
"relationType": "uses",
"properties": {
"weight": 0.8,
"since": "2024-01-01"
}
}
]Add observations to existing entities. Entity can be identified by ID or name/type.
Input (using name/type):
{
"category": "work",
"override": false,
"observations": [
{
"entityName": "UserService",
"entityType": "service",
"contents": [
{
"observationType": "version",
"text": "Updated to v2.0",
"timestamp": "2025-11-19T14:30:00Z",
"source": "changelog",
"properties": {
"semver": "2.0.0",
"breaking": true
}
},
{
"observationType": "feature",
"text": "Added caching",
"source": "changelog"
}
]
}
]
}Note: override: true updates existing observations (matched by observationType+source) instead of skipping them.
Input (using entity ID):
{
"category": "work",
"observations": [
{
"entityId": "1",
"contents": [
{
"observationType": "version",
"text": "Updated to v2.0",
"timestamp": "2025-11-19T14:30:00Z",
"source": "release-notes"
}
]
}
]
}Output:
[
{
"entityId": "1",
"entityName": "UserService",
"entityType": "service",
"addedObservations": [
{
"id": "3",
"observationType": "version",
"text": "Updated to v2.0",
"timestamp": "2025-11-19T14:30:00Z",
"source": "changelog",
"properties": {
"semver": "2.0.0",
"breaking": true
}
},
{
"id": "4",
"observationType": "feature",
"text": "Added caching",
"timestamp": "2025-11-19T14:30:01Z",
"source": "changelog"
}
]
}
]Delete entities and their relations. Identify by ID or name/type.
Input (using name/type):
{
"category": "work",
"entities": [
{
"name": "UserService",
"entityType": "service"
}
]
}Input (using ID):
{
"category": "work",
"entities": [
{ "id": "1" }
]
}Output:
"Entities deleted successfully"Delete specific observations. Identify by observation ID or by entity + observationType + source.
Input (using observation ID):
{
"category": "work",
"deletions": [
{ "id": "3" }
]
}Input (using entity name + observationType + source):
{
"category": "work",
"deletions": [
{
"entityName": "UserService",
"entityType": "service",
"observationType": "version",
"source": "changelog"
}
]
}Input (using entity ID + observationType + source):
{
"category": "work",
"deletions": [
{
"entityId": "1",
"observationType": "version",
"source": "changelog"
}
]
}Output:
"Observations deleted successfully"Delete relations. Identify by relation ID or composite key.
Input (using relation ID):
{
"category": "work",
"relations": [
{ "id": "1" }
]
}Input (using composite key):
{
"category": "work",
"relations": [
{
"from": "APIController",
"fromType": "controller",
"to": "UserService",
"toType": "service",
"relationType": "uses"
}
]
}Output:
"Relations deleted successfully"Get entire knowledge graph for a category.
Input:
{
"category": "work"
}Output:
{
"entities": [
{
"id": "1",
"name": "UserService",
"entityType": "service",
"observations": [
{
"id": "1",
"text": "Manages user data",
"timestamp": "2025-11-19T10:00:00Z"
}
]
}
],
"relations": [
{
"id": "1",
"from": "APIController",
"fromType": "controller",
"to": "UserService",
"toType": "service",
"relationType": "uses"
}
]
}Search by name, type, observation content, or properties (all searchable via FTS5).
Input:
{
"category": "work",
"query": "authentication"
}Output:
{
"entities": [
{
"id": "2",
"name": "AuthService",
"entityType": "service",
"observations": [
{
"id": "5",
"text": "Handles authentication",
"timestamp": "2025-11-19T10:30:00Z"
}
]
}
],
"relations": [
{
"id": "3",
"from": "APIController",
"fromType": "controller",
"to": "AuthService",
"toType": "service",
"relationType": "uses"
}
]
}Get specific entities. Identify by ID or name/type.
Input (using name/type):
{
"category": "work",
"entities": [
{
"name": "UserService",
"entityType": "service"
},
{
"name": "AuthService",
"entityType": "service"
}
]
}Input (using IDs):
{
"category": "work",
"entities": [
{ "id": "1" },
{ "id": "2" }
]
}Output:
{
"entities": [
{
"id": "1",
"name": "UserService",
"entityType": "service",
"observations": [...]
},
{
"id": "2",
"name": "AuthService",
"entityType": "service",
"observations": [...]
}
],
"relations": [
{
"id": "2",
"from": "UserService",
"fromType": "service",
"to": "AuthService",
"toType": "service",
"relationType": "depends_on"
}
]
}Get all available category names.
Input:
{}Output:
["work", "personal", "project-alpha"]Delete entire category and its database.
Input:
{
"category": "old-project"
}Output:
"Category 'old-project' deleted successfully"Track module dependencies per project:
{
"category": "backend-service",
"entities": [
{
"name": "AuthModule",
"entityType": "module",
"observations": [
{
"text": "Exports login, logout",
"source": "code-analysis"
}
]
},
{
"name": "UserModule",
"entityType": "module",
"observations": [
{
"text": "User CRUD operations",
"source": "documentation"
}
]
},
{
"name": "Database",
"entityType": "library",
"observations": [
{
"text": "PostgreSQL client"
}
]
}
]
}Then create relations:
{
"category": "backend-service",
"relations": [
{
"from": { "name": "AuthModule", "type": "module" },
"to": { "name": "UserModule", "type": "module" },
"relationType": "imports"
},
{
"from": { "name": "AuthModule", "type": "module" },
"to": { "name": "Database", "type": "library" },
"relationType": "uses"
}
]
}Query dependencies:
{"category": "backend-service", "query": "AuthModule"}Separate categories per project:
project-frontend - Frontend dependencies
project-backend - Backend dependencies
project-mobile - Mobile app dependencies
Keep contexts isolated:
work - Professional contacts and projects
personal - Personal notes and relationships
learning - Study notes and resources
npm run build # Compile TypeScript
npm run watch # Watch modenpm test # Run all tests (141 tests)Coverage: SQLiteStorage 98%, CategoryManager 87%, KnowledgeGraphManager 100%
src/
├── index.ts # MCP server
├── storage/
│ └── SQLiteStorage.ts # Database operations
├── managers/
│ ├── CategoryManager.ts # Category lifecycle & LRU cache
│ └── KnowledgeGraphManager.ts # Graph operations
└── types/
└── graph.ts # Type definitions
tests/
├── storage/ # Storage layer tests
├── managers/ # Manager tests
├── integration/ # End-to-end tests
└── benchmarks/ # Performance benchmarksDatabase: SQLite 3 with WAL mode
Schema: Single version, clean slate
Indexes: On entity names, types, relations
Transactions: ACID-compliant operations
Connection Limit: Max 50 concurrent (LRU eviction)
Parameterized queries (SQL injection protection)
Category name validation (path traversal prevention)
Foreign key constraints
Cascading deletes
Indexed queries for fast lookups
WAL mode for concurrent reads
Connection caching with LRU eviction
Batch operations via transactions
SQLite uses WAL mode which allows concurrent reads. If you get lock errors:
Ensure no other process is writing to the database
Check file permissions on the database directory
CategoryManager implements LRU cache with default 50 connection limit. Oldest connections automatically closed when limit reached.
MIT License
Original work Copyright (c) 2025 Anthropic, PBC Modified work Copyright (c) 2025 DanNsk
Based on @modelcontextprotocol/server-memory
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Add new observations to existing entities. Entity can be specified by entityId OR by entityName/entityType. Returns observation IDs. Constraint: observations unique by (entity, observationType, source). Use override=true to update existing observations.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Memory category. Defaults to 'default' | |
| override | No | If true, update existing observations instead of skipping them. Defaults to false | |
| observations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Mentions uniqueness constraint and override behavior, but misses details on idempotency, permissions, or error handling for non-existent entities.
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?
Two focused sentences plus a constraint sentence. No fluff, front-loaded with main verb.
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?
Covers purpose, identification, constraint, override, return value. Missing details on entity existence validation and error scenarios, but adequate for a well-structured 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?
Adds context beyond schema: entity identification alternatives, return value, and constraint. Schema covers most parameters but description enriches understanding.
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?
Description clearly states 'Add new observations to existing entities' and specifies entity identification methods and return value. Distinguishes from siblings like delete_observations or create_entities.
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?
Implies usage for adding observations but lacks explicit guidance on when not to use or alternatives. No comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple new entities in the knowledge graph. Returns entities with their assigned IDs. Constraints: entities unique by (name, entityType); observations unique by (entity, observationType, source). Use override=true to replace existing entities.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Memory category (e.g., 'work', 'personal', 'project-alpha'). Defaults to 'default' | |
| override | No | If true, replace existing entities instead of skipping them. Defaults to false | |
| entities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers return values (assigned IDs), uniqueness constraints, and override behavior. However, it lacks details on error handling (e.g., behavior on duplicate without override), idempotency, or authentication needs.
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?
Two concise sentences plus a line for constraints. Front-loaded with purpose. Every sentence adds value, no redundant information.
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 complex nested structure (entities with observations) and no output schema, the description covers key points but omits specifics like error messages, partial failure behavior, or the exact effect of override (replace vs update). Adequate but not exhaustive.
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?
With 67% schema description coverage, the schema already documents most parameters. The description adds value by explaining uniqueness constraints and the override flag, which goes beyond the schema's individual parameter descriptions.
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 states the tool creates multiple new entities in the knowledge graph and returns assigned IDs. It distinguishes itself from siblings like add_observations (which adds to existing entities) and create_relations.
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 constraints on uniqueness and when to use override, giving context on usage. However, it does not explicitly exclude cases when alternatives should be used (e.g., when to use add_observations instead of including observations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple new relations between entities. Each endpoint (from/to) can be specified by id OR by name/type. Returns relations with their assigned IDs. Use override=true to update existing relations.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Memory category. Defaults to 'default' | |
| override | No | If true, update existing relations instead of skipping them. Defaults to false | |
| relations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it creates relations, returns IDs, and allows updates via override. However, it omits details on error handling (e.g., missing endpoints), side effects, or permissions. With no annotations, the description carries full burden but provides only partial coverage.
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?
Three sentences, front-loading the main purpose. Concise and efficient, though could be slightly more structured (e.g., bullet points for clarity).
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 no output schema, the description mentions return value (IDs) and override behavior. However, it lacks context on error scenarios, default category, or contrast with sibling tools like 'delete_relations'. Adequate but not thorough.
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 coverage is 67%, so baseline is 3. The description adds value by explaining endpoint specification (id or name/type) and override behavior, but much of this repeats schema info. It does not compensate for the missing description on the 'relations' parameter.
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 states the tool creates multiple relations between entities and specifies how endpoints are identified. However, it does not explicitly differentiate from siblings like 'create_entities' or 'delete_relations', leaving some ambiguity.
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 on when to use this tool versus alternatives. The description mentions an override option but does not discuss exclusions or prerequisites, such as needing entities to exist first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an entire memory category and all its contents.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Memory category to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adequately indicates the destructive nature by stating 'delete' and 'all its contents,' but lacks details on reversibility, permissions, or side effects.
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?
A single, well-structured sentence that efficiently conveys the tool's purpose without unnecessary 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?
For a simple tool with one parameter and no output schema, the description covers the essential behavior. It could mention what happens to related data or if the action is reversible, but it is largely sufficient given the sibling 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?
The single parameter 'category' has a description in the schema that matches the purpose. The description adds no additional meaning beyond the schema's documentation.
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 states the action ('Delete'), the resource ('entire memory category'), and the scope ('all its contents'), effectively distinguishing it from sibling tools that delete specific items.
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 on when to use this tool vs. alternatives like delete_entities or delete_observations. It does not mention when not to use it or what prerequisites are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete entities and their relations. Specify each entity by id OR by name/entityType.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Memory category. Defaults to 'default' | |
| entities | Yes | An array of entities to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that relations are also deleted (cascading behavior), but does not state whether the operation is permanent, require authorization, or handle errors. The basic destructive effect is clear, but additional details (e.g., irreversibility) would improve 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 two sentences long, front-loading the main action: 'Delete entities and their relations.' Every sentence adds value, with no unnecessary words or repetition.
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's simplicity (2 parameters, 1 required, no output schema) and 100% schema coverage, the description covers the core behavior and identification method. However, it lacks details on return values, error handling, behavior when both id and name/entityType are provided, and whether the action is reversible. This is adequate but not fully complete.
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 coverage is 100%, so the schema already documents all parameters. The description reinforces the two identification methods (id vs name/entityType) but does not add new constraints or examples. It provides mild additional clarity but not significant extra meaning.
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 states the tool's action ('Delete entities and their relations') and specifies the identification method (by id or name/entityType). This provides a specific verb and resource, distinguishing it from sibling tools like create_entities or delete_relations.
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 delete_relations (for relations only) or delete_category. It does not mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete specific observations. Specify by observation id OR by entity identifier + observationType + source.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Memory category. Defaults to 'default' | |
| deletions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states that it deletes observations. It does not disclose whether deletion is irreversible, requires permissions, or has side effects (e.g., cascade deletions). The deletion behavior is implied but not elaborated.
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 (two sentences, 16 words), front-loads the purpose, and has no wasted content. Every word is necessary and informative.
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 no output schema and no annotations, the description should cover behavior like return values, error handling, and side effects. It does not address what happens if observations are not found, whether multiple deletions are atomic, or if any prerequisites exist. The description is incomplete for a deletion 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?
Schema description coverage is 50%, but the description adds value by concisely summarizing the two identification patterns: 'by observation id OR by entity identifier + observationType + source.' This clarifies the relationship between parameters beyond what individual field descriptions provide. However, the schema already has comparable descriptions for each parameter, so the added value is moderate.
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 states the tool deletes observations and specifies two identification methods (by observation ID or by entity identifier + observationType + source). This differentiates it from sibling tools like delete_entities and delete_relations, which target different resources.
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, nor does it mention prerequisites or conditions for use. The agent must infer usage based on the resource name ('observations' vs siblings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete relations. Specify by relation id OR by entity IDs (fromId/toId/relationType) OR by entity names (from/fromType/to/toType/relationType).
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Memory category. Defaults to 'default' | |
| relations | Yes | An array of relations to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It explains the input methods but omits side effects, reversibility, permissions, or rate limits—important for a deletion operation.
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, information-dense sentence that front-loads the purpose. It could be slightly restructured for readability, but contains no superfluous 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?
No output schema exists, yet the description does not indicate what happens after deletion (e.g., success message, deleted count). It also lacks guidance on choosing among sibling tools, though the tool's specific purpose is clear.
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 100% coverage with individual property descriptions. The description adds value by grouping parameters into the three logical alternatives (by id, by entity IDs, by entity names), clarifying the trade-offs beyond what the schema provides.
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 states the verb 'Delete relations' and specifies three explicit methods (by relation id, by entity IDs, by entity names), making the tool's purpose obvious and distinguishing it from sibling tools like delete_entities or delete_observations.
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 clear guidance on how to specify which relations to delete (by id, entity IDs, or entity names), but does not explain when to use this tool versus alternatives like delete_entities or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available memory categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source for behavioral traits. It states the tool lists all categories, implying a read-only operation, but does not disclose any additional behaviors like whether results are paginated or if there are side effects.
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, clear sentence. Every word is meaningful and front-loaded with the action and object.
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?
For a simple, parameterless list tool, the description is nearly complete. It could mention if the list is ordered or filtered, but given no output schema and low complexity, it adequately informs 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?
There are no parameters, so the description does not need to add meaning beyond the schema. The schema coverage is 100% (no parameters), meeting the baseline for this dimension.
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 'List all available memory categories' uses a specific verb and resource, clearly stating the tool's function. It distinguishes from sibling tools that perform different actions like adding observations or creating entities.
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 (e.g., search_nodes or read_graph). There is no context for when listing categories is appropriate or when other tools might be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open specific entities. Specify each by id OR by name/entityType. Returns entities with their IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Memory category. Defaults to 'default' | |
| entities | Yes | An array of entities to retrieve |
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. It states that it returns entities with IDs, but does not mention if the operation is read-only, requires authentication, or what happens if entities are not found. This is insufficient for a retrieval 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 extremely concise with two sentences, no wasted words, and the key purpose is front-loaded. Every sentence adds value.
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 has no output schema and no annotations. The description does not explain the return format in detail, error behavior, or prerequisites. For a simple retrieval tool, it lacks completeness in contextualizing the full behavior.
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 coverage is 100%, so the baseline is 3. The description adds a brief clarification on the OR condition between id and name/entityType, but mostly reiterates schema descriptions. It does not provide additional semantics beyond what is already in 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 states the verb 'Open' and the resource 'specific entities', and explains how to specify them (by id or name/entityType). This distinguishes it from siblings like search_nodes (search) and create_entities (create).
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 implies usage when you know entity identifiers, but it does not explicitly state when not to use it or provide alternatives. The sibling search_nodes is a natural alternative for unknown entities, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the entire knowledge graph. Returns all entities (with IDs) and relations (with IDs).
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Memory category. Defaults to 'default' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It states return contents but omits safety aspects (e.g., read-only nature), performance implications (potentially large result), or side effects. The term 'Read' hints at non-modifying behavior but is not explicit.
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 two sentences, front-loaded with the action, and contains no unnecessary words. Every word provides information.
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?
For a simple read tool with no output schema, the description covers the basics but lacks detail on return format beyond presence of IDs. It does not mention limits, pagination, or structure of entities/relations. Competes well with sibling complexity but incomplete without output schema.
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 only parameter 'category' is fully described in the schema (default, purpose). The description adds no extra meaning beyond what the schema provides. With 100% schema description coverage, baseline 3 is appropriate.
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 states the tool reads the entire knowledge graph and specifies what is returned (all entities and relations with IDs). This distinguishes it from siblings like search_nodes or list_categories which have narrower scope.
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 implies usage for a full graph read but lacks explicit guidance on when not to use it or alternatives. Sibling tools are provided externally but not referenced in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search with BM25 ranking. Returns matching entities sorted by relevance. Supports FTS5 query syntax: simple terms (auth), phrases ("user auth"), AND/OR/NOT operators (user AND auth), prefix matching (auth*), proximity search (NEAR(user auth, 5)). Simple queries auto-convert to prefix-matching AND search.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Memory category. Defaults to 'default' | |
| query | Yes | FTS5 search query. Examples: 'authentication', 'user AND auth', '"user authentication"', 'auth*', 'user OR admin' | |
| limit | No | Maximum number of results to return. Defaults to 50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As annotations are absent, the description carries full burden. It explains the BM25 algorithm, relevance sorting, and detailed FTS5 query syntax with auto-conversion. Missing are potential error conditions or permission requirements, but core behavior is well-covered.
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 with two sentences that front-load the purpose and then detail query syntax. Every sentence adds value without redundancy.
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 lacks details about the structure of returned entities (e.g., fields, scores) and pagination behavior, leaving gaps for an agent to understand the output. While the query behavior is well-explained, the absence of output schema means more completeness is needed.
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 100% coverage, but the description adds valuable context for the query parameter by explaining FTS5 syntax and auto-conversion, enriching semantic meaning beyond the schema descriptions.
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 tool as a full-text search over entities with BM25 ranking and relevance sorting. This distinguishes it from sibling tools like read_graph or add_observations, which are not search-focused.
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 explicit guidance on when to use this tool versus alternatives is provided. Since no other search tool exists among siblings, the usage is implied, but explicit recommendations for scenarios or exclusions would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a specific resource or action: entities, relations, observations, categories, graph reading, and search. The deletion tools are clearly differentiated by object type (entities, observations, relations, categories). Retrieval tools (open_nodes, read_graph, search_nodes) serve distinct purposes.
All tool names follow a verb_noun pattern with lowercase and underscores (e.g., create_entities, delete_observations). However, the verbs vary: 'add' vs 'create' for creation, and 'open' is an unusual choice for retrieval, introducing slight inconsistency.
With 11 tools, the server covers the essential operations for managing a knowledge graph (CRUD for entities, relations, observations, plus categories, graph reading, and search). The count is well within the typical 3-15 range and feels appropriate for the domain.
The tools cover create, read, delete, and search operations, but lack update functionality for entities and relations (e.g., update_entity, update_relation). Also, categories can only be listed and deleted, not created or renamed. These gaps limit completeness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Personal wiki and memory layer for AI assistants. Persistent, structured memory across sessions.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
Persistent memory and knowledge graph for AI assistants — keyword + vector + graph search.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DanNsk/multi-memory-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
