Labsco
n-r-w logo

KnowledgeGraph MCP Server

★ 24

from n-r-w

Enables persistent knowledge storage for Claude using a knowledge graph with multiple database backends like PostgreSQL and SQLite.

🔥🔥🔥✓ VerifiedFreeQuick setup
#email#automation#database#devops#git#maps#monitoring#memory

MseeP.ai Security Assessment Badge

WARNING

I've become disillusioned with automated context management tools like this, as it's nearly impossible to control. After a while, I always have to manually clean up the mess or correct inappropriate LLM notes. Instead, I created a tool that gives the LLM agent access to dynamically loaded context. However, the context itself is user-created: https://github.com/n-r-w/agent-standards-mcp

KnowledgeGraph MCP Server

A simple way to give LLMs persistent memory across conversations. This server lets Claude or vscode remember information about you, your projects, and your preferences using a knowledge graph.

Key Features:

  • Multiple Storage Backends: PostgreSQL (recommended) or SQLite (local file)
  • Project Separation: Keep different projects isolated (auto-detected using prompts)
  • Better Search: Find information with fuzzy search and pagination

How It Works - LLM Power Features

The knowledge graph enables powerful queries through four interconnected concepts:

1. Entities - Your Knowledge Nodes

Store people, projects, companies, technologies as searchable entities.

Real Example - Project Management:

{
  "name": "Sarah_Chen",
  "entityType": "person",
  "observations": ["Senior React developer", "Leads frontend team", "Available for urgent tasks"],
  "tags": ["developer", "team-lead", "available"]
}

LLM Benefit: Find "all available team leads" instantly with tag search.

2. Relations - Enable Discovery Queries

Connect entities to answer complex questions like "Who works on what?"

Real Example - Team Structure:

{
  "from": "Sarah_Chen",
  "to": "Project_Alpha",
  "relationType": "leads"
}

LLM Benefit: Query "Find all projects Sarah leads" or "Who leads Project Alpha?"

3. Observations - Atomic Facts

Store specific, searchable facts about entities.

Real Examples - Actionable Information:

  • "Available for urgent tasks" → Find available people
  • "Uses React 18.2" → Find projects with specific tech
  • "Deadline: March 15, 2024" → Find upcoming deadlines

4. Tags - Instant Filtering

Enable immediate status and category searches.

Real Examples - Project Workflow:

  • ["urgent", "in-progress", "frontend"] → Find urgent frontend tasks
  • ["completed", "bug-fix"] → Track completed bug fixes
  • ["available", "senior"] → Find available senior staff

Available Tools

The server provides these tools for managing your knowledge graph:

Data Creation Tools

create_entities

CREATE new entities (people, concepts, objects) in knowledge graph.

  • WHEN: Use for entities that don't exist yet
  • CONSTRAINT: Each entity MUST have ≥1 non-empty observation
  • BEHAVIOR: Ignores entities with existing names (use add_observations to update)

Input:

  • entities (Entity[]): Array of entity objects. Each REQUIRES:
    • name (string): Unique identifier, non-empty
    • entityType (string): Category (e.g., 'person', 'project'), non-empty
    • observations (string[]): Facts about entity, MUST contain ≥1 non-empty string
    • tags (string[], optional): Exact-match labels for filtering
  • project_id (string, optional): Project name to isolate data

create_relations

CONNECT entities to enable powerful queries and discovery.

  • IMMEDIATE BENEFITS: Find all people at a company, all projects using a technology, all dependencies
  • CRITICAL FOR: Team structures, project dependencies, technology stacks
  • EXAMPLES: 'John works_at Google', 'React depends_on JavaScript', 'Project_Alpha managed_by Sarah'

Input:

  • relations (Relation[]): Array of relationship objects. Each REQUIRES:
    • from (string): Source entity name (must exist)
    • to (string): Target entity name (must exist)
    • relationType (string): Relationship type in active voice (works_at, manages, depends_on, uses)
  • project_id (string, optional): Project name to isolate data

add_observations

ADD factual observations to existing entities.

  • REQUIREMENT: Target entity must exist, ≥1 non-empty observation per update
  • BEST PRACTICE: Keep observations atomic and specific

Input:

  • observations (ObservationUpdate[]): Array of observation updates. Each REQUIRES:
    • entityName (string): Target entity name (must exist)
    • observations (string[]): New facts to add, MUST contain ≥1 non-empty string
  • project_id (string, optional): Project name to isolate data

add_tags

ADD status/category tags for INSTANT filtering.

  • IMMEDIATE BENEFIT: Find entities by status (urgent, completed, in-progress) or type (technical, personal)
  • REQUIRED: For efficient project management and quick retrieval
  • EXAMPLES: ['urgent', 'completed', 'bug', 'feature', 'personal']

Input:

  • updates (TagUpdate[]): Array of tag updates. Each REQUIRES:
    • entityName (string): Target entity name (must exist)
    • tags (string[]): Status/category tags to add (exact-match, case-sensitive)
  • project_id (string, optional): Project name to isolate data

Data Retrieval Tools

read_graph

RETRIEVE complete knowledge graph with all entities and relationships.

  • USE CASE: Full overview, understanding current state, seeing all connections
  • SCOPE: Returns everything in specified project

Input:

  • project_id (string, optional): Project name to isolate data

search_knowledge

SEARCH entities by text or tags. SUPPORTS MULTIPLE QUERIES for batch searching.

  • MANDATORY STRATEGY: 1) Try searchMode='exact' first 2) If no results, use searchMode='fuzzy' 3) If still empty, lower fuzzyThreshold to 0.1
  • EXACT MODE: Perfect substring matches (fast, precise)
  • FUZZY MODE: Similar/misspelled terms (slower, broader)
  • TAG SEARCH: Use exactTags for precise category filtering
  • MULTIPLE QUERIES: Search for multiple objects in one call with automatic deduplication

Input:

  • query (string | string[], optional): Search query for text search. Can be a single string or array of strings for multiple object search. OPTIONAL when exactTags is provided for tag-only searches.
  • searchMode (string, optional): "exact" or "fuzzy" (default: "exact"). Use fuzzy only if exact returns no results
  • fuzzyThreshold (number, optional): Fuzzy similarity threshold. 0.3=default, 0.1=very broad, 0.7=very strict. Lower values find more results
  • exactTags (string[], optional): Tags for exact-match searching (case-sensitive). Use for category filtering
  • tagMatchMode (string, optional): For exactTags: "any"=entities with ANY tag, "all"=entities with ALL tags (default: "any")
  • page (number, optional): Page number for pagination (0-based, default: 0)
  • pageSize (number, optional): Number of results per page (1-1000, default: 50)
  • project_id (string, optional): Project name to isolate data

Examples:

  • Basic search: search_knowledge(query="JavaScript", searchMode="exact")
  • Paginated search: search_knowledge(query="React", page=0, pageSize=20)
  • Large dataset: search_knowledge(query="components", page=2, pageSize=100)
  • Multiple queries: search_knowledge(query=["JavaScript", "React"], page=0, pageSize=30)
  • Tag + pagination: search_knowledge(query="React", exactTags=["frontend"], page=1, pageSize=25)
  • Tag-only search: search_knowledge(exactTags=["urgent", "bug"], tagMatchMode="all") - NO QUERY NEEDED

Pagination Benefits:

  • Performance: Database-level pagination with OFFSET/LIMIT for efficient large dataset handling
  • Memory: Reduces memory usage by limiting results per request
  • Navigation: Pagination metadata provides totalPages, currentPage, and navigation hints
  • Scalability: Handles knowledge graphs with thousands of entities efficiently

open_nodes

RETRIEVE specific entities by exact names with their interconnections.

  • RETURNS: Requested entities plus relationships between them
  • USE CASE: When you know exact entity names and want detailed info

Input:

  • names (string[]): Array of entity names to retrieve
  • project_id (string, optional): Project name to isolate data

Data Management Tools

delete_entities

PERMANENTLY DELETE entities and all their relationships.

  • WARNING: Cannot be undone, cascades to remove all connections
  • USE CASE: Entities no longer relevant or created in error

Input:

  • entityNames (string[]): Array of entity names to delete
  • project_id (string, optional): Project name to isolate data

delete_observations

REMOVE specific observations from entities while keeping entities intact.

  • USE CASE: Correct misinformation or remove obsolete details
  • PRESERVATION: Entity and other observations remain unchanged

Input:

  • deletions (ObservationDeletion[]): Array of deletion requests. Each REQUIRES:
    • entityName (string): Target entity name
    • observations (string[]): Specific observations to remove
  • project_id (string, optional): Project name to isolate data

delete_relations

UPDATE relationship structure when connections change.

  • CRITICAL FOR: Job changes (remove old 'works_at'), project completion (remove 'assigned_to'), technology migration (remove old 'uses')
  • MAINTAINS: Accurate network structure and prevents confusion
  • WORKFLOW: Always remove outdated relations when creating new ones

Input:

  • relations (Relation[]): Array of relations to delete. Each REQUIRES:
    • from (string): Source entity name
    • to (string): Target entity name
    • relationType (string): Exact relationship type to remove
  • project_id (string, optional): Project name to isolate data

remove_tags

UPDATE entity status by removing outdated tags.

  • CRITICAL: For status tracking - remove 'in-progress' when completed, 'urgent' when resolved
  • MAINTAINS: Clean search results and accurate status
  • WORKFLOW: Always remove old status tags when adding new ones

Input:

  • updates (TagUpdate[]): Array of tag removal requests. Each REQUIRES:
    • entityName (string): Target entity name
    • tags (string[]): Outdated tags to remove (exact-match, case-sensitive)
  • project_id (string, optional): Project name to isolate data

Development and Testing

Multi-Backend Testing

This project includes comprehensive multi-backend testing to ensure compatibility across both SQLite and PostgreSQL:

Run tests against both backends:

npm run test:multi-backend

Run all tests (original + multi-backend):

npm run test:all-backends

Using Taskfile (if installed):

task test:multi-backend
task test:comprehensive

Development Setup

Clone and setup:

git clone https://github.com/n-r-w/knowledgegraph-mcp.git
cd knowledgegraph-mcp
npm install
npm run build

Run tests:

npm test                    # All tests including multi-backend
npm run test:unit          # Unit tests only
npm run test:performance   # Performance benchmarks

Based on MCP Memory Server

This is an enhanced version of the official MCP Memory Server with additional features:

  • Multiple Storage Options: PostgreSQL (recommended) or SQLite (local file)
  • Project Separation: Keep different projects isolated
  • Better Search: Find information with fuzzy search
  • Easy Setup: Docker support and simple installation