Knowledge Graph MCP Server

Create a new knowledge graph. Supports multiple graph types such as topology, timeline, changelog, requirement documentation, etc. Design guidelines for each graph type: - topology: Used to represent dependencies between system components and modules. Recommended to first create main module nodes, then add component nodes, and finally represent relationships through edges like calls, dependencies, and containment - timeline: Used to record important project events and decisions. Recommended to add event nodes in chronological order and link related personnel and decisions - changelog: Used to track change history of features and components. Recommended to create nodes for each significant change, marking change types and impact scope - requirement: Used for requirement management and tracking. Recommended to first create high-level requirements, then break down into specific features, and finally link to responsible persons and iterations - knowledge_base: Used to build domain knowledge systems. Recommended to start from core concepts and gradually expand related concepts and relationships - ontology: Used for formal representation of domain concepts and relationships, suitable for building standardized knowledge models

Add a node to the knowledge graph. Nodes are the basic units of the graph, and different types of graphs support different types of nodes.

在知识图谱中添加边，连接两个节点以构建关系网络。边表示节点之间的关系类型，如依赖、包含、关联等。 使用前提： 1. 必须先创建图谱（使用create_graph） 2. 必须已经创建了源节点和目标节点 3. 边的类型必须与图谱类型匹配 使用建议： 1. 先使用list_graphs获取图谱和节点信息 2. 确认源节点和目标节点都存在且类型匹配 3. 根据图谱类型选择合适的边类型 4. 为边添加有意义的标签，帮助理解关系 5. 如果关系有强弱之分，可以通过weight参数表示 返回数据： - data: 新创建的边信息 * id: 边ID * type: 边类型 * sourceId: 源节点ID * targetId: 目标节点ID * label: 边标签 * weight: 边权重

Publish a knowledge graph, changing its status from draft to published. Published graphs can still be modified, but it's recommended to track important changes through version management. Prerequisites: 1. Graph must exist and be in draft status 2. Recommended to ensure graph content is complete before publishing 3. Ensure all necessary nodes and edges have been added Usage recommendations: 1. First use list_graphs to check the current status of the graph 2. Use get_node_details to check the completeness of key nodes 3. Review the graph structure before publishing 4. Record publication time for version management 5. Notify relevant team members after publication Return data: - data: Published graph information * id: Graph ID * name: Graph name * type: Graph type * status: Published * publishedAt: Publication time

List all knowledge graphs with support for filtering by status and type. This is the main tool for getting information about existing graphs and an important path for obtaining node IDs. Use cases: 1. View all available graphs and their basic information 2. Get the node list of a specific graph for subsequent edge addition or node detail queries 3. Filter graphs by status, such as viewing all drafts or published graphs 4. Filter graphs by type, such as viewing only topology or timeline graphs Usage recommendations: 1. First call this tool to get the graph list and node information 2. Get the required graph ID and node ID from the returned data 3. Use these IDs to call other tools (like add_edge, get_node_details) 4. Recommended to use this tool to confirm the target graph's status before performing any node or edge operations Return data: - data: List of graphs, each graph contains: * id: Graph ID (used for graphId parameter in other tools) * name: Graph name * description: Graph description * type: Graph type * status: Graph status * nodesCount: Number of nodes * edgesCount: Number of edges * createdAt: Creation time * updatedAt: Update time * publishedAt: Publication time (if published) * nodes: Node list, each node contains: - id: Node ID (used for add_edge and get_node_details tools) - name: Node name - type: Node type