How do I use Knowledge Graph MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Knowledge Graph MCP Server Recommend the next concept to study in calculus." 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.

Knowledge Graph MCP Server

by zcsabbagh

Overview Schema Related Servers Score Discussions

Python

Local

Knowledge Graph MCP Server

An MCP (Model Context Protocol) server for tracking student learning via a knowledge graph. Built with FastMCP, it enables LLMs to build, query, and update a personalized knowledge map with spaced repetition scheduling.

Features

Knowledge Graph Storage: SQLite-backed graph with concepts as nodes and relationships as edges
Multi-dimensional Mastery Tracking: Track recall, application, and explanation abilities separately
Spaced Repetition (SM-2): Automatic scheduling of review sessions based on performance
Misconception Tracking: Record and query common misconceptions for targeted remediation
Intelligent Queries: Find knowledge gaps, ready-to-learn concepts, struggling areas
Mermaid Visualization: Generate visual diagrams of the knowledge graph

Related MCP server: Learning Orchestrator MCP

Installation

Option 1: Install from Smithery (Recommended)

Install directly via Smithery:

npx @smithery/cli install @zcsabbagh/knowledge-graph-mcp --client claude

Or use the hosted version at: https://smithery.ai/server/@zcsabbagh/knowledge-graph-mcp

Option 2: Install from source

Prerequisites: Python 3.10+

git clone https://github.com/zcsabbagh/knowledge-graph-mcp.git
cd knowledge-graph-mcp
pip install -e .

Usage

Running the Server

# From the project root
python -m knowledge_graph_mcp.server

Configure with Claude Code

Add to your Claude Code MCP settings (~/.claude/settings.json):

{
  "mcpServers": {
    "knowledge-graph": {
      "command": "python",
      "args": ["-m", "knowledge_graph_mcp.server"],
      "cwd": "/path/to/knowledge-graph-mcp"
    }
  }
}

Configure with Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "knowledge-graph": {
      "command": "python",
      "args": ["-m", "knowledge_graph_mcp.server"],
      "cwd": "/path/to/knowledge-graph-mcp"
    }
  }
}

MCP Tools

1. `add_node`

Create a new concept node.

add_node(
  concept="Quadratic Formula",
  description="Formula for solving ax² + bx + c = 0",
  domain="mathematics",
  difficulty=0.7,
  tags=["algebra", "formulas"]
)

2. `add_edge`

Create relationships between concepts.

Relation types:

prerequisite - Must learn source before target
builds_on - Target extends source concept
related_to - Concepts are connected
contradicts - Common misconception
applies_to - Application domain
parent_of - Category hierarchy

add_edge(
  source_concept="Algebra",
  target_concept="Quadratic Formula",
  relation_type="prerequisite"
)

3. `update_node`

Update mastery and record reviews. Providing a quality rating (0-5) triggers spaced repetition scheduling.

update_node(
  node_id="quadratic_formula",
  quality=4,  # SM-2 rating: 0=blackout, 5=perfect
  mastery_application=0.6,
  misconception_detected="forgets ± sign"
)

4. `query_graph`

Intelligent queries for learning insights.

Query types:

prerequisites - All prerequisites for a concept
ready_to_learn - Concepts where prereqs are mastered
due_for_review - Needs review based on schedule
struggling - High difficulty + low mastery
stalled - Multiple reviews, no improvement
misconceptions - Concepts with detected misconceptions
knowledge_gaps - Low mastery blocking progress
next_recommended - Best concept to study next

query_graph(query_type="next_recommended", domain="mathematics")

5. `read_subgraph`

Get the neighborhood around a concept with Mermaid visualization.

read_subgraph(
  center_node="calculus",
  depth=2,
  direction="upstream",  # or "downstream", "both"
  output_format="both"   # "json", "mermaid", or "both"
)

6. `get_learning_path`

Get ordered prerequisites for a target concept.

get_learning_path(target_concept="calculus")

7. `get_statistics`

Get learning progress metrics.

get_statistics(domain="mathematics")

How It Works

Data Model

Nodes represent concepts with:

Mastery levels (overall, recall, application, explanation)
Spaced repetition data (ease factor, interval, next review date)
Difficulty rating and review history
Tags and detected misconceptions

Edges represent relationships with:

Relation type (prerequisite, builds_on, etc.)
Strength/confidence rating
Optional reasoning

Spaced Repetition (SM-2)

When you call update_node with a quality rating:

5: Perfect response → longer interval
4: Correct with hesitation
3: Correct with difficulty
2-0: Incorrect → reset interval

The algorithm calculates the next optimal review date based on performance history.

Mastery Calculation

Overall mastery combines dimensional scores:

mastery_level = 0.3 × recall + 0.4 × application + 0.3 × explanation

Storage

Data is stored in SQLite at ~/.knowledge_graph/knowledge.db by default.

Example Workflow

1. LLM discovers student doesn't know "quadratic formula"
   → add_node(concept="Quadratic Formula", difficulty=0.7)

2. LLM identifies prerequisites
   → add_edge("Algebra", "Quadratic Formula", "prerequisite")

3. Student attempts problem, struggles
   → update_node("quadratic_formula", quality=2,
                 misconception_detected="confuses ± with +")

4. LLM decides what to teach next
   → query_graph("next_recommended")

5. Visualize the learning path
   → get_learning_path("quadratic_formula")

License

MIT

Available Tools

7 tools

add_edgeB

Create a relationship between two concepts in the knowledge graph.

ParametersJSON Schema

Name	Required	Description
`source_concept`	Yes	Source node ID or concept name
`target_concept`	Yes	Target node ID or concept name
`relation_type`	Yes	Type of relationship. One of: - "prerequisite": Source must be learned before target - "builds_on": Target extends/deepens source concept - "related_to": Concepts are connected (bidirectional semantically) - "contradicts": Common misconception (source is wrong belief about target) - "applies_to": Source concept applies to target domain/topic - "parent_of": Ontological hierarchy (source is parent category of target)
`strength`	No	Confidence in the relationship from 0.0 to 1.0. Default 1.0.
`reasoning`	No	Explanation of why this relationship exists

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as idempotency, side effects, or permission requirements beyond the basic creation action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no extraneous information, achieving high conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description does not explain return values or provide behavioral context. With no annotations, the description is insufficient for a tool with 5 parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All five parameters are fully described in the input schema (100% coverage), so the description adds minimal additional meaning, earning the baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a relationship between two concepts, distinguishing it from sibling tools like add_node which adds nodes, and query_graph which queries the graph.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not specify when to use this tool versus alternatives, nor does it mention any conditions for use or avoidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

add_nodeB

Create a new concept node in the knowledge graph.

ParametersJSON Schema

Name	Required	Description
`concept`	Yes	Human-readable name for the concept (e.g., "Quadratic Formula")
`description`	No	Detailed description of what this concept represents
`domain`	No	Category/domain (e.g., "mathematics", "physics", "programming")
`difficulty`	No	Estimated cognitive load from 0.0 (easy) to 1.0 (hard). Default 0.5.
`tags`	No	List of categorization tags (e.g., ["algebra", "equations"])
`node_id`	No	Custom ID for the node. Auto-generated from concept if not provided.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behaviors. It mentions creation but no details about idempotency, duplicate handling, required permissions, or side effects. The return value is not described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, which is efficient but lacks structure. It does not expand on important details, making it too minimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters and a rich schema, the description only states the core function. It omits explanation of output, parameter semantics, and usage context, leaving gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 6 parameters are documented in the schema with descriptions, achieving 100% coverage. The description adds no additional parameter context beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a new concept node in the knowledge graph, using a specific verb and resource. It distinguishes itself from siblings like add_edge.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like update_node or add_edge. No context about prerequisites or scenarios for use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_learning_pathA

Get the ordered learning path to reach a target concept.

Returns a topologically sorted list of prerequisites, highlighting which concepts the student still needs to learn (gaps).

ParametersJSON Schema

Name	Required	Description	Default
`target_concept`	Yes	The goal concept to learn (node ID or concept name)
`include_mastered`	No	Whether to include already-mastered concepts in the path

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses it returns a sorted list and highlights gaps, but lacks details on side effects, authentication, rate limits, or whether it's read-only. Adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose, second adds key detail. Every word adds value. No redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and well-documented parameters, the description covers the tool's purpose and behavior reasonably. Could mention that path is student-specific or clarify ordering, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions. Description adds brief context (e.g., target_concept is goal, include_mastered defaults false) but does not significantly extend beyond schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Get the ordered learning path to reach a target concept' and explains it returns a topologically sorted list of prerequisites, highlighting gaps. This distinguishes it from siblings like query_graph or read_subgraph.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 vs alternatives like query_graph or read_subgraph. The description implies usage for learning paths but does not state exclusions or alternative scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_statisticsA

Get summary statistics for learning progress.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	No	Filter statistics by domain (e.g., "mathematics"). If None, returns all.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description does not disclose behavioral traits such as idempotency, side effects, or data freshness. The brief description offers no insight beyond purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with one sentence, which is efficient. However, it could be slightly expanded to include context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description provides sufficient context. It does not need to detail return values as per guidelines.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema adequately documents the parameter. The description adds no additional meaning 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves summary statistics for learning progress. It uses a specific verb and resource, and is easily distinguishable from sibling tools that operate on graph nodes/edges.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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. While sibling names suggest different purposes, the description lacks any when-to-use or when-not-to-use advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_graphC

Query the knowledge graph for learning insights.

ParametersJSON Schema

Name	Required	Description
`query_type`	Yes	Type of query to execute. One of: - "prerequisites": All prerequisites for a concept (requires node_id) - "ready_to_learn": Concepts where all prerequisites are mastered - "due_for_review": Nodes where scheduled review date has passed - "struggling": High difficulty + low mastery concepts - "stalled": Multiple reviews but mastery not improving - "misconceptions": Nodes with detected misconceptions - "knowledge_gaps": Low mastery nodes blocking other concepts - "next_recommended": Smart recommendation for what to study next - "all_nodes": All nodes in the graph
`node_id`	No	Focus node for some queries (required for "prerequisites")
`domain`	No	Filter results by domain (e.g., "mathematics")
`limit`	No	Maximum number of results to return. Default 10.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, and the description does not disclose behavioral traits such as read-only nature, side effects, or performance implications. The query operation implies reading, but this is not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single-sentence description is concise but under-specified. It could be front-loaded with a brief summary of query types to improve usefulness without adding length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema, the description does not mention it or summarize the various query types listed in the schema. The tool is complex, yet the description lacks completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Query the knowledge graph for learning insights' vaguely states the tool's purpose but does not differentiate it from sibling tools like get_learning_path or read_subgraph, which also query the graph for learning data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. The description does not mention conditions, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_subgraphB

Get the neighborhood around a concept for context.

ParametersJSON Schema

Name	Required	Description	Default
`center_node`	Yes	Node ID or concept name to center on
`depth`	No	How many edge hops to traverse (1=direct connections, 2=neighbors of neighbors)
`direction`	No	Which edges to follow: - "upstream": Follow edges where center is target (prerequisites) - "downstream": Follow edges where center is source (what it unlocks) - "both": Follow edges in both directions	both
`include_mastery`	No	Whether to include mastery data in response
`output_format`	No	Output format: - "json": Just the structured data - "mermaid": Just the Mermaid diagram - "both": Both JSON and Mermaid (default)	both

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It is a read operation (implied by name), but the description does not disclose behavioral details such as response structure, performance implications, or whether it modifies state. Minimal information beyond purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, making it concise. However, for a tool with 5 parameters and no annotations, it is overly brief and could include more contextual information without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters and no annotations, the description is too minimal. The presence of an output schema helps but does not compensate for missing usage guidelines and behavioral details. The description is not complete enough for complex decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add any meaning beyond what the input schema provides; it simply restates the tool's overall purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get the neighborhood around a concept for context' clearly states the tool retrieves a subgraph centered on a concept. This distinguishes it from sibling tools like add_edge (mutations), get_learning_path, get_statistics, and query_graph.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, no exclusions, and no context for appropriate usage. It only states what it does, leaving the agent to infer when to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_nodeC

Update a node's properties and record a review session.

ParametersJSON Schema

Name	Required	Description
`node_id`	Yes	ID or concept name of the node to update
`mastery_level`	No	Overall mastery (0.0-1.0). Overrides dimensional calculation.
`mastery_recall`	No	Ability to retrieve from memory (0.0-1.0)
`mastery_application`	No	Ability to use in new contexts (0.0-1.0)
`mastery_explanation`	No	Ability to teach/explain to others (0.0-1.0)
`quality`	No	SM-2 review quality rating (0-5). Triggers spaced repetition scheduling. - 5: Perfect response - 4: Correct after hesitation - 3: Correct with serious difficulty - 2: Incorrect, but correct answer seemed easy - 1: Incorrect, correct answer remembered after seeing it - 0: Complete blackout
`difficulty`	No	Update estimated difficulty (0.0-1.0)
`misconception_detected`	No	Specific misconception observed (e.g., "confuses ± with +")
`notes`	No	LLM observations about the student's understanding

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description must disclose behavioral traits. It mentions 'record a review session' but does not explain side effects, overwrite behavior, or implications for spaced repetition scheduling. The schema hints at SM-2, but the description lacks clarity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise and front-loaded. It avoids verbosity, but could be slightly more structured without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, no annotations, and an output schema (not described), the description is insufficient. It does not explain the spaced repetition context or how properties relate, leaving significant gaps for an AI agent to understand full usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage with clear descriptions for all 9 parameters, including ranges and defaults. The description adds minimal value beyond the schema, only providing high-level context that ties parameters to a review session.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (update) and the resource (node properties) along with 'record a review session', which distinguishes it from sibling tools like add_node (create) or read_subgraph (read). However, it lacks specificity about the learning system context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like add_node or query_graph. The description implies usage for updating and recording, but does not state conditions or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0May 26, 2026
- First observedadd_edge
- First observedadd_node
- First observedget_learning_path
- First observedget_statistics
- First observedquery_graph
- First observedread_subgraph
- First observedupdate_node

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool targets a distinct operation: adding/updating nodes/edges, querying subgraphs, getting learning paths, and statistics. There is no ambiguity between tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_edge, get_learning_path), making them predictable and clear.

Tool Count5/5

With 7 tools, the set is well-scoped for a knowledge graph server covering creation, updates, queries, and analytics without unnecessary bloat.

Completeness3/5

The set covers core CRUD for nodes and edges but missing delete operations for both nodes and edges, which is a notable gap for lifecycle completeness.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Math MCP Learning A
io.github.clouatre-labs
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Education & Learning Tools Research & Data Developer Tools
1725
brainkb B
org.brainkb
MCP server for querying BrainKB, a knowledge base for neuroscience knowledge graphs.
Knowledge & Memory Biology & Medicine
5324
Mirror Memory MCP Server
io.github.Tr1ckyMag1ca1
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
Knowledge & Memory Search Note Taking
2
hjarni AOAuth
com.hjarni
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Note Taking Workplace & Productivity
3

Related MCP Servers

Axial Coach
Education & Learning Tools Autonomous Agents
aaryaa8
F
license
Not graded
quality
C
maintenance
MCP server that exposes a student's cognitive profile as read-only tools for Sauna, enabling proactive coaching with gamified quests and holistic parent reports.
Updated 2 months ago (2026-07-17 02:13 UTC)
-
Learning Orchestrator MCP
Developer Tools Education & Learning Tools Knowledge & Memory
SEOSiri-Official
A
license
B
quality
A
maintenance
A sovereign, AI-driven pedagogical and spaced-repetition skills development MCP server supporting progressive syllabi, Bloom's Taxonomy, and secure LMS handshakes.
Updated 2 months ago (2026-07-18 13:48 UTC)
5
MIT
primer
Education & Learning Tools Knowledge & Memory
VedSoni-dev
A
license
Not graded
quality
A
maintenance
An MCP server that provides an open, local-first record of a child's learning, enabling an AI tutor to read, teach from, and update the child's knowledge, interests, and progress.
Updated a month ago (2026-08-05 22:15 UTC)
1
Apache 2.0
learning-mcp
Education & Learning Tools Knowledge & Memory
ryantthomas
A
license
A
quality
C
maintenance
An MCP server that enforces a pedagogical workflow to teach topics step by step, using research, decomposition, and spaced retrieval practice.
Updated a month ago (2026-08-05 03:17 UTC)
7
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zcsabbagh/knowledge-graph-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Knowledge Graph MCP Server

Features

Installation

Option 1: Install from Smithery (Recommended)

Option 2: Install from source

Usage

Running the Server

Configure with Claude Code

Configure with Claude Desktop

MCP Tools

1. add_node

2. add_edge

3. update_node

4. query_graph

5. read_subgraph

6. get_learning_path

7. get_statistics

How It Works

Data Model

Spaced Repetition (SM-2)

Mastery Calculation

Storage

Example Workflow

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `add_node`

2. `add_edge`

3. `update_node`

4. `query_graph`

5. `read_subgraph`

6. `get_learning_path`

7. `get_statistics`