This server provides a fully automated, three-stage knowledge graph construction system that processes raw text into structured knowledge graphs.
Core Capability — Build Knowledge Graphs: The single comprehensive tool accepts raw text and runs it through a three-stage pipeline:
Stage 1 – Data Quality Assessment: Evaluates input text for completeness, consistency, and relevance, assigning a composite quality score.
Stage 2 – Knowledge Completion (for low-quality data): Infers missing entities/relationships, resolves conflicts, and normalizes data formats using LLMs and external knowledge bases. High-quality input skips this stage.
Stage 3 – Knowledge Graph Construction: Extracts entities and triples using a hybrid rule-based + LLM approach, assigns confidence scores, and generates an interactive HTML visualization.
Structured Output: Returns a JSON object containing:
Extracted entities
Knowledge triples (subject, predicate, object) with confidence scores
Processing stage details
Path to an interactive HTML visualization (color-coded, Plotly-powered network graph)
Additional Features:
Integrates with OpenAI-compatible LLMs (e.g., OpenAI, DeepSeek, SiliconFlow) for semantic understanding
Supports multilingual input
Automatically routes input based on quality, skipping enhancement for high-quality data
Utilizes OpenAI-compatible APIs to perform intelligent semantic understanding, relationship inference, and knowledge enhancement for automated knowledge graph construction.
Generates interactive HTML-based network visualizations of knowledge graphs, featuring clickable nodes, entity clustering, and confidence-coded visualizations.
Click on "Deploy 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., "@MCP-based Knowledge Graph Construction System Create a knowledge graph and visualization from this text about the history of AI."
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.
项目包含知识图谱构建与修复代码、两篇论文，以及对应的实验记录。论文当前入口如下。
要做什么 | 打开哪里 |
修改、阅读 Paper1 当前稿 | |
修改、阅读 Paper2 当前稿 | |
下载 Paper1 完整 Overleaf 项目 | |
下载 Paper2 完整 Overleaf 项目 | |
阅读 Paper1 完整中文译文 | |
看老师的原稿、合并前的 Paper1 | |
找文件、了解本次整理 |
目录或文件 | 用途 |
| 两篇论文的当前源码、PDF 和 Overleaf 交付包 |
| 合并前 Paper1 的压缩归档、老师原稿，以及实验使用的画图样式文件 |
| 图谱检查、修复和评价代码 |
| 实验代码、冻结配置、输出和评分结果；实验索引 |
| 数据集、图谱 CSV 和规则测试数据 |
| 数据转换、数据准备、监控和规则工具 |
| 离线验证和原有测试 |
| 使用说明、方法解释和目录说明 |
| 旧论文、旧导出包、历史文档和运行日志 |
| 程序生成的图谱等输出 |
| 原有程序入口和模块；保留路径以便现有命令和实验继续使用 |
Related MCP server: Universal Ontology MCP
main.tex、sections/、figure/、文献、模板和字体：当前论文的编译输入。
main.pdf：当前阅读版。Paper1 的 main_zh.pdf 是完整中文译文。
overleaf/ 和 ZIP：从当前源码生成的交付副本。日常修改根目录源码，下载时用 ZIP。
docs/：数学与实验导读、进度、合并说明和投稿材料；不参与论文编译。
tools/、validation/：构建工具和核对记录；不需要上传到 Overleaf。
archive/：历史版本和旧材料，已退出当前编译流程，保留以便追溯。
上传 Overleaf 时选择完整 ZIP，主文件选 main.tex，编译器选 XeLaTeX。
更新约定：每次修改并完成相应验证后，提交并推送到 origin/main。论文源码、PDF 和 Overleaf 交付包同步更新。老师的 paper1/zt/ 原稿继续仅保留在本地。
在仓库根目录执行：
uv sync
uv run kg_server.pyAPI 配置保存在本地 .env 或 apis。配置示例是 .env.example、apis.example。
全自动构建知识图谱：自动评估数据质量、补全知识、构建图谱并生成可视化
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 要处理的文本数据 | |
| output_file | No | 可视化输出文件名（可选） | knowledge_graph.html |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool's automated processes but fails to disclose critical traits like required permissions, rate limits, whether it's read-only or destructive, or what happens on failure. For a complex tool with no annotation coverage, this is a significant gap in 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 highly concise and front-loaded, using a single sentence that efficiently outlines the tool's multi-step process. Every phrase ('自动评估数据质量、补全知识、构建图谱并生成可视化') earns its place by specifying key actions without redundancy or waste.
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 complexity (automated knowledge graph construction) and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects, error handling, or output details, leaving gaps that could hinder an AI agent's effective use. The description should provide more context to compensate for missing structured data.
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 100%, so the schema already documents both parameters ('text' and 'output_file'). The description adds no additional meaning beyond the schema—it doesn't explain parameter interactions, formats, or constraints. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
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 purpose: '全自动构建知识图谱' (fully automatic knowledge graph construction) with specific verbs like '评估数据质量' (assess data quality), '补全知识' (complete knowledge), '构建图谱' (build graph), and '生成可视化' (generate visualization). It distinguishes the tool's comprehensive automated workflow. However, without sibling tools, we cannot assess differentiation from alternatives, preventing a perfect score.
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 guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It simply lists what the tool does without context for application. This lack of usage instructions limits its utility for an AI agent in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0build_knowledge_graphScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'build_knowledge_graph' has a clearly defined and distinct purpose for constructing knowledge graphs.
Since there is only one tool, naming consistency is inherently perfect. The tool name 'build_knowledge_graph' follows a clear verb_noun pattern, and there are no other tools to compare it against for inconsistency.
A single tool for a 'Knowledge Graph Construction System' is too few for the apparent scope. The domain suggests needs for operations like querying, updating, or analyzing graphs, but only construction is covered, making the set feel thin and incomplete.
The tool set is severely incomplete for a knowledge graph system. It only provides construction with visualization, lacking essential operations such as querying, updating, deleting, or analyzing the graph, which are critical for agent workflows in this domain.
Universal Document Intelligence: 70+ formats & 75+ languages to LPG/RDF entities & tables (13 tools)
Knowledge graph ingestion, entity search, ontology analysis, and CoPass scoring.
Map text into knowledge graphs to create a structured representation of conceptual relations and t…
Knowledge graph ingestion, entity search, ontology analysis, and CoSync scoring.
