Standalone MCP server for graph-based long-term memory using FalkorDB graph database with semantic search capabilities
Graph Memory MCP demonstrates solid definition quality with 18 well-structured tools. All tools have descriptions and input schemas with parameter types. Most tools follow verb-noun naming conventions (create_node, search, get_context, etc.). However, several tools lack comprehensive descriptions of output schemas, and some parameter descriptions could be more explicit about constraints and formats. Error handling guidance is minimal. Tool annotations are present (via Risk field), which is good. The server shows clear domain expertise in graph memory operations but lacks some of the polish needed for A-grade (80+), specifically around detailed output documentation and error recovery guidance.
Create a node (Fact or Entity). Required: `text`, Optional: `node_type` ('Fact' default, or 'Entity'), `owner_id`, `metadata`, `source` (provenance dict with keys like ref/type/uri/content_hash/updated_at/version), `auto_link` (Facts only), `ttl_days` (Facts only), `links` (create relations immediately after creation). Note: auto_link=true (default) on Facts adds MENTIONS edges to similar Entity nodes (vector search on Entity index; threshold AUTO_LINKING_SEMANTIC_THRESHOLD). Use create_relation for links between arbitrary node pairs. Set ttl_days for automatic archival.
Create a directed edge between two nodes with optional properties. Relations are user-defined; common patterns: MENTIONS, REFERENCES, RELATED_TO, PARENT_OF, etc.
Delete a node and its relations. Use mark_outdated for soft deletes.
Delete a directed edge between two nodes.
Create or verify Fact and Entity vector indexes for semantic search. Idempotent — safe to call multiple times. Indexes are also created automatically on first search or auto_link when missing; set AUTO_CREATE_INDEXES=true to create them at server startup.
Output schemas are not documented in tool descriptions. While input parameters are well-defined with types, return value structures are not explicitly described. LLMs cannot plan downstream tool calls or extract required fields without knowing what each tool returns.
Several read-only operations (get_node, get_trace, delete_node, delete_relation, find_similar) lack explicit guidance on expected result sizes and pagination. Tools that could return large result sets need to document limits and whether pagination is supported.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 66 | - | v1 |
Find similar nodes using embedding-based semantic similarity. Similar to search but returns nodes with highest cosine distance to the query, potentially including metadata and relation context.
Get subgraph context around a node. Traverses relations up to a specified depth and returns all connected nodes and edges.
Retrieve a single node (Fact or Entity) by its ID.
Retrieve the version history of a node. Returns snapshots ordered by version.
Get graph statistics (node counts, etc.).
Get shortest path between two nodes.
Check server health (FalkorDB, embeddings, vector index).
Mark a node as outdated (does not delete). Useful for deprecation workflows.
Semantic search using embedding similarity (cosine distance). Returns active nodes by default (use include_outdated=true to include outdated and archived nodes). Results ranked by similarity to query text. Supports multi-tenant isolation via owner_id. search_type: pre_filter (filter owner first, best for large/multi-tenant graphs) or post_filter (global ANN then filter, best for small graphs); defaults to server SEARCH_TYPE when omitted.
Search for semantic patterns in the form (subject)-[relation]->(object). Returns triplets ranked by semantic relevance to the query.
Simple ping to verify MCP server availability.
Update a node (Fact or Entity). You can update text, metadata, status, or ttl_days. Optional provenance updates use the same structure as source. Set versioning=true to store a previous snapshot and auto-increment version when it is omitted.
Create or update a node using `source.ref` as a stable sync key. Required: `text`, `source.ref`. Optional: same fields as create_node, plus `versioning=true` to store a version snapshot and auto-increment `source.version` when it is omitted.
Error handling descriptions are minimal. Tools do not document what errors are possible, which are retryable, or what recovery actions an LLM should take. For example, delete_node could fail if the node has critical incoming relations, but this is not mentioned.
Some parameter descriptions lack explicit constraints. For example, 'limit' in search and find_similar do not state the maximum allowed value or default. 'semantic_threshold' lacks units (is it 0-1? percentage?). 'depth' in get_context is described as 'bounded by server config' but the bound is not stated.
Destructive operations (delete_node, delete_relation) lack confirmation or dry-run patterns. The descriptions do not mention whether these operations are fully irreversible or whether there are recovery options (e.g., restore from versioning or audit trail).
Parameter 'links' in create_node and related creation tools is described as an array but its element structure (object schema) is not documented. LLMs cannot construct valid link objects without knowing required fields (from_id? to_id? relation_type?).