ontopoc
OntoPoc 是一个还在开发中的方向,不是成品。在试的是:从几张业务表或一份文档起草本体,由代码对照数据检查草稿,再由人逐项确认并存下来。现在没有作者以外的用户,也还没和直接用通用编程助手(例如 Claude Code 加 pandas、DuckDB)做同样的事比过。
简介
用户上传若干业务表(Excel、CSV)或一份流程文档后,OntoPoc 生成本体草案,包括业务中的对象、各对象的识别字段以及对象之间的关系。起草时,代码先在全部行上数出每列有几种值、哪些列每行都不同、哪些列的值能在别的列里找到,模型看字段名、至多 3 个示例值和这些计数起草;代码再按 14 类错误检查草稿,例如字段是否存在、识别字段是否有值、关系有没有连上的行,不通过就退回,至多 3 轮。在此基础上,系统执行数据质量检查,并基于数据回答业务问题。文档也可按「组织架构」读,梳理出组织单元、岗位、人与工作环节及其隶属、协作、交接关系,每条都附原文出处。顾问逐项确认后,结果将被保存;同一文件或其新版本再次上传时,系统以此为基准进行比对。
数据里说不清、只有客户答得了的事,代码汇总成一张“要确认的事”清单,每条附依据和一句可以直接问客户的话;每张表另有一张口径卡,写明一行是什么、日期是什么时间、数值能不能相加。会上记下客户的答复,问答即按这些答复计算。
建模结果可按数据平台的对象表单导出,可导出给搭数据管道的人看的编排需求单和一页会议纪要,也可按 W3C 标准导出为 Turtle(OWL 与 SHACL);主要功能也已封装为 MCP 工具,可供其他 Agent 调用。
早期版本。 目前只在公开数据和合成数据上试过(美国联邦采购、芝加哥市政合同、Northwind、BART 地铁、台湾公司登记、CMS 医院等)。尚无作者以外的用户独立完成全流程,也还没和通用编程助手直接做同一件事比过。页面仅在 macOS 上实际用过;尚未在任何数据平台上实测批量导入。单个文件,或一次上传的多张表合计,不超过 10 MB;模型只接 DeepSeek 的托管接口,没有本地模型选项。详见已知问题。
Related MCP server: OWL MCP Server
界面预览
以上截图均基于仓库内置的合成示例 examples/company/demo_company.xlsx,由无头浏览器离屏渲染。
工作原理
操作 | 系统行为 |
打开左侧“本体库” | 搜索、按领域浏览 12 份 Playground 参考本体,在图上查看对象、属性和关系;也可导入 RDF/XML 格式的 |
上传数据表并填写建模目的 | 代码先在全部行上数出每列有几种值、哪些列每行都不同、哪些列的值能在别的列里找到;模型读取每列字段名、至多 3 个示例值和这些计数,提出对象、识别字段与关系;代码按 14 类错误校验,不通过则退回修改,至多 3 轮 |
建模完成 | 同一文件并行建模 3 次,标出三次结果不一致的地方,交给人判断;三次只比对象和关系,不比属性。建模目的里写了问题的,一并用数据算出答案,可直接存为验收问题 |
打开“要确认的事” | 代码从数据、问答和确认记录里汇总要和客户确认的事,例如关系连不上的行、名字相同编号不同的对象、问答里模型自己加的筛选条件;每条附依据和一句可以直接问客户的话。会上点“记下客户的回答”,答复随运行保存 |
打开“口径卡” | 每张表一张:一行是什么、日期列是什么时间、数值列能不能相加。代码能算的已经算好,只有客户答得了的格留给会上填;填好的答复用于问答计算,并写进编排需求单 |
打开"数据体检" | 代码对数据执行 7 项检查,例如同一编号的属性是否冲突、每张上传的表是否均被使用。关系一项只要求每条关系至少连上一行,页面会写出连上了多少行 |
智能问答 | 模型将问题转写为结构化查询,由代码基于数据计算答案;无法回答时说明原因:本体缺失、数据缺失或查询不支持。需要按公式算的金额(单价 × 数量 ×(1 − 折扣))由模型提出公式,代码在每一行上试算,确认后原题重算并答出。答案带有模型自己加的筛选条件时单独列出,可去掉该条件重算。也可以让模型按需出一组 6 道题 |
查看关系绑定 | 显示来源表与两端编号列,如 |
逐项确认、重命名、补充对象 | 保存为该文件的参考本体,再次上传时自动比对并预填 |
设定验收问题(至多 3 道) | 每次重新运行以相同查询复算,仅提示结果发生变化的问题 |
采纳数据规则 | 每次重新运行均校验,列出违反规则的对象 |
标记上传文件为新版本 | 沿用上一版的确认(含判错)、验收问题与规则,并统计各对象的新增与减少数量;模型再次提出此前判错的对象时单独提示 |
生成对象表单草稿 | 一次模型调用,生成中文名称、描述与展示字段;人工修改过的内容不会被再次生成覆盖 |
导出对象表单 | 每个对象生成一份 CSV,列为数据平台建对象时的常见表单列 |
点击右上角"⤓ TTL" | 导出三份 Turtle 文件: |
点击右上角“⤓ 编排需求单” | 下载压缩包(Markdown 与 JSON 各一份),交给搭数据管道的人:数据体检、要确认的事、口径卡答复、已确认的指标与已采纳的规则对数据准备提出的要求,每条注明出处(代码在数据里查到、客户答复或人工确认)。不调用模型,也不改数据 |
点击右上角“⤓ 纪要”或按 ⌘K | 纪要:一页 Markdown,要确认的事排在最前,供会上使用;⌘K:在这次运行里搜索对象、字段、关系和表,并跳到所在位置 |
模型只负责判断,循环与计算均由代码完成;模型调用串联至多 3 步,每次调用都对应一个需要人来做的判断。系统共有 6 个 Agent,定义见 docs/AGENTS.md。
快速体验
完成安装(见快速开始)后,可用仓库内置的合成示例体验:
操作 | 预期结果 |
不启动建模服务,点击"打开示例数据表" | 显示内置结果:4 个对象、3 条关系 |
上传 | 约半分钟至一分钟后生成客户、产品、订单、售后工单 4 个对象;数据体检 5 / 7 项通过,未通过的 2 项即示例中预置的问题;“智能问答 › 提问”里这道题已用数据答出 |
打开“要确认的事” | 内置示例是 8 件要和客户确认的事(件数随三次建模是否一致而变),其中包括预置的问题:客户 KH012 在两行里城市不同,订单引用的 KH099 不在客户表里 |
在智能问答中提问"每个客户的订单总金额是多少?" | 按客户排序的合计金额,最高为 241,420,共计 160 个值 |
本体关系 → 实例图谱,选择一个客户 | 以图谱展示该客户及其订单,点击订单可继续展开产品 |
点击右上角"⤓ 表单" | 下载压缩包,内含 4 份对象表单 CSV 及一份导入说明 |
快速开始
环境要求:Python 3.11+、Node 22+,以及 DeepSeek API key。上传 PDF 另需本机装有 pdftotext(poppler)。
方式 A:由 AI 助手安装
将以下内容粘贴至 Claude Code 或 Codex:
请在本机安装并运行 OntoPoc(https://github.com/Longado/ontopoc):
1. 阅读仓库的 README.md,按"快速开始"操作。
2. 检查 python3 --version ≥ 3.11、node --version ≥ 22;不满足时告诉我安装方法,并暂停后续步骤。
3. 克隆仓库,在仓库根目录执行 python3 -m pip install -e .(安装读 Excel 用的 openpyxl;系统 Python 不允许直接安装时,先建虚拟环境),在 landing-page 目录执行 npm ci。
4. 向我索取 DeepSeek API key,仅写入当前终端的环境变量 DEEPSEEK_API_KEY,不要写入任何文件。
5. 在仓库根目录启动建模服务:PYTHONPATH=src python3 -m ontology_poc_generator.ontology_server
6. 另开一个终端启动页面:cd landing-page && npm run dev -- --host 127.0.0.1 --port 5178 --strictPort
7. 打开 http://127.0.0.1:5178,上传 examples/company/demo_company.xlsx,告诉我"数据体检"通过了几项。方式 B:手动安装
git clone https://github.com/Longado/ontopoc.git && cd ontopoc
python3 -m pip install -e . # 读 Excel 用的 openpyxl;系统 Python 不允许时先 python3 -m venv .venv && . .venv/bin/activate
(cd landing-page && npm ci)
# 终端 1:建模服务(端口 8767,结果保存在 output/ontology-runs/)
export DEEPSEEK_API_KEY=你的key
PYTHONPATH=src python3 -m ontology_poc_generator.ontology_server
# 终端 2:页面
cd landing-page && npm run dev -- --host 127.0.0.1 --port 5178 --strictPort访问 http://127.0.0.1:5178。未配置 key 时仍可查看内置示例。修改后端代码后需重启建模服务,页面检测到服务运行旧代码时会提示。
用 MCP / Claude 接入
OntoPoc 的主要功能已封装为 32 个 MCP 工具,也可作为 Claude Code 插件安装。工具与页面共用本机建模服务:先启动服务,再接入客户端。
作为 Claude Code 插件安装
仓库本身就是一个 Claude Code 插件。安装后可在 Claude Code 里直接建本体、逐项确认;建模、核验和确认记录仍在本机 OntoPoc 服务里完成,使用前需要先启动它(见上文)。
claude plugin marketplace add Longado/ontopoc
claude plugin install ontopoc@ontopoc新开一个会话后可用两个命令:/ontopoc:ontopoc-build(上传文件建本体)与 /ontopoc:ontopoc-review(逐项确认)。会话开始时,若本机服务没有运行,插件会提示一行。插件按 ONTOPOC_PYTHON、python3、python 的顺序寻找 Python。
接入 Claude Code 或其他 MCP 客户端
页面上的主要功能都有对应的 MCP 工具,共 32 个。这些工具与页面共用同一个本机服务,可在 Claude Code 等客户端中直接调用(在仓库根目录运行):
claude mcp add ontopoc -- env PYTHONPATH=$PWD/src python3 -m ontology_poc_generator.mcp_server工具清单见 docs/MCP.md。
功能模块
模块 | 内容 |
本体库 | 12 份 Playground 参考本体,按领域浏览、在图上看对象和关系;可导入 RDF/XML 格式的 |
要确认的事 | 要和客户确认的事,每条附依据、可直接问客户的一句话和“记下客户的回答”;可下载会议纪要 |
口径卡 | 每张表一张:一行是什么、日期列是什么时间、数值列能不能相加、对象全不全;记下答复人与出处 |
数据接入 | 每张上传表的行数、跳过的标题行,以及各列的类型、长度、填充率;表之间未连通时,提示可用于关联的列 |
本体管理 | 对象卡片(支持搜索、按确认结果筛选、卡片与列表视图);对象详情页:概览、属性(即对象表单)、数据(分页浏览、导出 CSV)、确认;另含逐项确认、稳定性、和上次比、新版本与建模记录 |
本体关系 | 自动布局的关系图(支持拖拽与缩放)、实例图谱、关系列表;代码从数据中发现、本体中尚未包含的关系以虚线标示为建议 |
组织架构 | 上传公开研究材料时选「组织架构」:组织树、协作交接(箭头上写明交接内容)、角色表、时期、材料未说明之处;可导出 Mermaid 组织图,按年份段分别出图 |
智能问答 | 自由提问、验收问题、模型生成的问题(可按能否回答筛选) |
数据体检 | 7 项数据检查、数据规则、与参考本体比对 |
侧边栏“更多示例”里另有两个应用示例:用同一方法研判汽车召回范围(NHTSA 公开数据,不需要本机服务),以及食品召回事件 95876 的产品与批号匹配(openFDA,需另启本机召回服务),说明见 docs/RECALL_EXAMPLE.md。OntoPoc 与 NHTSA 及任何汽车厂商无关联,候选结果不构成缺陷认定。
本体 FAQ
什么是 ontology engineering(本体工程)?
在这里,本体工程(ontology engineering)是把业务里的对象、识别方式和对象之间的关系写成可检查的定义。OntoPoc 在试的做法是:从几张业务表或一份文档起草本体草案,由代码对照数据检查,再由人逐项确认后存下来。
Ontology 和 knowledge graph(知识图谱)有什么不同?
Ontology 先约定「有哪些对象、怎么识别、对象之间可以有什么关系」;knowledge graph 通常还包含具体的实例及其关系。OntoPoc 侧重前者:起草并核对定义,并在本次上传的数据上做检查与问答。它不是知识图谱平台,也不提供持久实例库或线上对象查询。
这和 semantic layer(语义层)是什么关系?
语义层常指在数仓或指标平台上,定义业务含义(对象、指标、口径)供查询复用。OntoPoc 做的是更靠前的一步:第一次拿到客户表或文档时,整理对象、识别字段、关系,以及需要和客户确认的口径;可导出对象表单、编排需求单和 Turtle(OWL / SHACL),交给后续的数据平台或管道工作。是否导入某个具体平台,目前尚未实测。
什么是 ontology MCP?可以怎么用?
这里的 ontology MCP 指通过 MCP 工具调用本体相关功能。OntoPoc 把页面上的主要能力做成 MCP 工具(共 32 个),供 Claude Code、Claude Desktop、Cursor 等支持 MCP 的客户端调用。工具走本机 stdio,调用的是本机正在运行的建模服务。Claude Code 也可直接装仓库插件后使用 /ontopoc:ontopoc-build 与 /ontopoc:ontopoc-review。接法见用 MCP / Claude 接入,工具清单见 docs/MCP.md。
OntoPoc 现在适合谁用?
设想中的使用者是数据平台的实施顾问:第一次拿到客户数据时,用它梳理业务对象及其关系。现在没有作者以外的用户独立完成全流程;页面仅在 macOS 上实际用过。更多边界见已知问题。
隐私
上传的文件及全部结果仅保存在本机
output/ontology-runs/目录。发送给模型(DeepSeek)的内容仅包括:建模目的;每张表的行数、各列字段名、至多 3 个示例值、代码数出的计数(有值个数、不同值个数、是否各不相同)、每张表每行都不同的列或两列组合、可能的连接(包括指向本表的);像类别那样反复出现的列的全部取值;生成问题时,取值不超过 12 种的列的全部取值,以及你在问答里输入的问题原文;点“起草”字段释义时,各字段的类型和最长长度;点“找出可能的对应”时,只用一个字段识别、取值 2–200 个的对象的全部识别值及各值出现的行数;文档则为正文,每次至多 12 段。建模时将发送的内容,上传前可在页面逐列查看。
每次模型调用在本机
output/ontology-runs/model_calls.jsonl记录一行(Agent、耗时、成功与否),不记录调用内容。服务仅接受本机请求。
已知问题
同类对象关系的问答方向尚不支持。 员工汇报、父子组织等关系可以按两端字段建模、核验和导出;当前问答遍历无法指定上级或下属方向,会说明限制并停止计算。
建模结果存在随机性。 同一文件三次建模结果常有差异,现在主要在关系上:10-28 在 Northwind 数据上的一次测量,8 类对象、7 条关系,其中 4 条关系三次结果不一致,几乎都是同一条关系方向反了(订单→客户 / 客户→订单)。差异之处会在页面中标出,由人工判断。
新旧版本的识别字段可能变化。 芝加哥合同数据曾有一次由"合同号 + 修订号"改为仅用合同号识别,此时只能比较数量,无法逐一比对,页面会注明"识别方式已变更"。
关系检查只要求至少连上一行。 数据体检里关系那一项,每条关系只要连上一行就算通过,连上的比例很低也一样;页面会写出连上了多少行,请看这个数。
关系推断的召回有限。 在 17 份已保存的运行(公开数据与合成数据)上逐条移除关系后重新推断,33 条中找回 24 条;在完整本体上未出现误报。
查询能力的限制。 暂不支持按数值条件筛选、限定时间范围、单个问题返回两个数值,以及"哪些项目经常同时出现"一类问题;遇到时系统会如实说明。
批量导入尚未实测。 导出的表单列按数据平台的常见表单整理,但导入格式、主键规则与关系表达因平台而异,尚未在任何平台上实测,因此暂不导出关系表。
TTL 仅用 rdflib 与 pyshacl 读回验证过。 尚未在 Protégé 或图数据库中实际导入。
页面仅在 macOS 上实际用过。 后端与页面的单元测试在 Linux(CI)上通过;Windows 尚未测试。
参与共建
业务人员能否自行读懂、修正本体,并在后续工作中持续使用?
方向 | 可贡献的内容 |
用户研究 | 邀请一位非作者的顾问独立完成从上传到导出纪要的全流程,记录受阻环节 |
数据质量 | 规则发现目前仅支持"必填"与"日期先后"两类,取值范围、非负等规则需先在真实数据上验证定义 |
平台对接 | 在具体数据平台上实测批量导入,补充关系表导出 |
提示词评测 | 从本机运行结果中选取已确认样本作为标注集,实现新旧提示词的一键对比 |
跨平台 | 在 Windows、Linux 上完整运行,并以 issue 形式反馈问题 |
欢迎提交 issue 或 pull request。开发前请先阅读开发规范。
开发
PYTHONPATH=src python3 -m unittest discover -s tests -q # 后端测试(1083 个;先 pip install -e ".[check]",否则 TTL 校验的 9 个跳过)
npm --prefix landing-page run test:unit # 前端测试(331 个)
PYTHONPATH=src:. python3 scripts/run_company_ontology.py --file examples/company/demo_company.xlsx --output output/demo-run.json
PYTHONPATH=src python3 -m ontology_poc_generator.ontology_server --data-dir /tmp/ontopoc-trial # 试跑用另一个数据目录,不动已有运行
PYTHONPATH=src:. python3 scripts/make_demo_company.py # 重新生成合成示例工作簿文档 | 内容 |
开发方向与边界 | |
本体库来源、RDF/XML 导入边界与后续轮次 | |
6 个 Agent 的定义与调用记录 | |
32 个 MCP 工具 | |
数据平台对象表单对照 | |
最近一份迭代计划(第 9 轮,闭环);之后各轮的改动见已合并 PR 的说明 | |
开发红线与待触发的方向 |
许可证
MIT © Yutai Lin
Available Tools
32 toolsask_questionA
用数据回答一个业务问题:模型把问题写成查询,代码在数据上算答案。不给 question 就让模型出一组题。会调用模型,慢且花钱。每道题有 status:answered 答出来了;no_data 数据里没有满足条件的对象;query_limit 查询写不出来、ontology_gap 本体缺回答它要的东西(reason_from_model 为 true 时是模型的判断;否则是代码查出来的原因,照 reason 告诉人);needs_derived 要一个派生指标,derive 里是公式和试算,人同意后才 confirm_derived。evidence 是代码给的核对依据:filters 是查询里的筛选条件(before、after 是筛前筛后的对象数,removed_measure 是筛掉的那部分的合计),其中 not_in_question 的是模型自己加的、题目没提,该不该加由人定,不加用 drop_filter 去掉重算;merged 是被算成同一个的对象组(同一个名字下有几个不同的识别值);found_elsewhere 是 no_data 时,这个值在别的对象里能找到的地方。口径卡:refused_by_card 是被卡上的哪一格拒答的(status 是 query_limit,reason 是代码给的),照 reason 告诉人,不要换问法绕过;evidence.card 是答案用了哪张表、数据到哪天(tables)、按哪几条口径(lines),incomplete 是对象在数据里只有一部分,要转告人。
Inputs: saved_as (required), question.
build_ontologyA
上传文件并建本体:模型提出、代码核验、数据体检、建三次比稳定性,并回答 purpose 里写的问题。给 previous 表示这是那次运行的新版本,沿用它的确认、验收问题和规则。会调用模型,等它跑完才返回;返回的概况同 run_overview,也带 open_items、answered_items、card。
Inputs: files (required), mode, purpose, previous.
compare_referenceB
拿一份人写的参考本体(JSON)和这次的本体对照:哪些对象、关系对上了,哪些多了、少了。
Inputs: saved_as (required), reference (required), reference_name.
confirm_derivedA
确认一个派生指标(例如 金额 = 单价 × 数量 ×(1 − 折扣)):服务再核一遍公式,存下后重算等它的题。只在人看过公式和试算结果、同意之后调用;derive 用那道题返回的 derive 原样传。
Inputs: derive (required), saved_as (required).
confirm_ontologyA
保存人对本体的逐项判断,成为这个文件的参考本体并马上对照。decisions 形如 {"types": {"<对象key>": {"verdict": "ok"|"wrong", "label": "改名(可选)"}}, "relations": {"<关系key>": {"verdict": "ok"|"wrong"}}, "added": ["漏掉的对象名"]}。
Inputs: saved_as (required), decisions (required), confirmed_by.
data_checkB
数据体检:七项检查是否通过,以及每类发现的数量和前几个例子。全部由代码算。
Inputs: saved_as (required).
data_layoutB
上传的每张表:行数、跳过的标题行、每列类型长度空值;表没连上时,能把它们连起来的列。
Inputs: saved_as (required).
draft_formA
让字段释义员起草对象表单里只有人能写的列:每个对象和字段的中文名、一句话描述、展示字段。一次模型调用;人写过的不会被覆盖。
Inputs: saved_as (required).
drop_filterA
去掉模型自己加在一道题上的一个条件,用本机代码重算,不调模型;新答案作为这道题新的一次追加到记录里并返回,想固定它再用 fix_question。用在人同意去掉模型自己加的条件之后(evidence.filters 里 not_in_question 的那些)。field、equals 两种写法都认:照 evidence.filters 里那一条写(字段不带表名),或照这道题 query.where 里那一条原样写(字段带不带表名以查询为准)。
Inputs: field (required), equals (required), question (required), saved_as (required).
export_formsA
按对象表单导出:每个对象一张 CSV(主键、展示、中文名称、英文名称、描述、类型、长度、属性类型)和一份说明。导入契约还没实测,说明里写着导入前要测。文件写到本机的一个文件夹(out_dir,默认在下载文件夹里),同名覆盖,只返回文件的路径和字节数 {dir, files: [{name, path, bytes}], total_bytes, removed},不返回文件内容。文件夹里会留一份清单 .ontopoc-export.json,记着这一类导出这次写了哪些文件;再导出到同一个文件夹时,上次清单里有、这次没有的文件会被删掉(removed 是删掉的文件名),清单以外的文件不碰。文件名必须是单纯的文件名,否则整次导出报错、一个文件也不写。
Inputs: saved_as (required), out_dir.
export_mermaidA
组织架构模式的运行导出组织图(Mermaid):组织隶属.mmd(隶属、汇报、担任)和协作交接.mmd(协作、交接及交接内容)。years 写 2016-2022 只画这段时间的关系,没写时间的关系每段都画;判错的不画。文件写到本机的一个文件夹(out_dir,默认在下载文件夹里),同名覆盖,只返回文件的路径和字节数 {dir, files: [{name, path, bytes}], total_bytes, removed},不返回文件内容。文件夹里会留一份清单 .ontopoc-export.json,记着这一类导出这次写了哪些文件;再导出到同一个文件夹时,上次清单里有、这次没有的文件会被删掉(removed 是删掉的文件名),清单以外的文件不碰。文件名必须是单纯的文件名,否则整次导出报错、一个文件也不写。
Inputs: saved_as (required), years, out_dir.
export_pipeline_specA
生成编排需求单,交给搭管道的人:把体检、要确认的事、口径卡、派生指标和采纳的规则里已经说了的“这份数据要怎么加工才能算对”合成一份清单——每张表要做的清洗、表之间怎么关联、按期取数、计算列、编排后的校验、还没说清的;每条写明来源(代码查出、客户答复、人确认)。写出 编排需求单.md 和 编排需求单.json。只描述要做什么,不执行加工,不调用模型,没有模型 key 也能导出。文档运行和没通过核验的运行没有需求单,服务的说明作为工具错误原样返回。文件写到本机的一个文件夹(out_dir,默认在下载文件夹里),同名覆盖,只返回文件的路径和字节数 {dir, files: [{name, path, bytes}], total_bytes, removed},不返回文件内容。文件夹里会留一份清单 .ontopoc-export.json,记着这一类导出这次写了哪些文件;再导出到同一个文件夹时,上次清单里有、这次没有的文件会被删掉(removed 是删掉的文件名),清单以外的文件不碰。文件名必须是单纯的文件名,否则整次导出报错、一个文件也不写。
Inputs: saved_as (required), out_dir.
export_ttlA
按 W3C 标准导出 Turtle:ontology.ttl(OWL 类、字段、关系、识别键)、data.ttl(每个对象按识别值命名,同一对象跨表跨版本同名)、shapes.ttl(采纳的规则写成 SHACL,有规则时才有)。判错的对象和关系不导出。文件写到本机的一个文件夹(out_dir,默认在下载文件夹里),同名覆盖,只返回文件的路径和字节数 {dir, files: [{name, path, bytes}], total_bytes, removed},不返回文件内容。文件夹里会留一份清单 .ontopoc-export.json,记着这一类导出这次写了哪些文件;再导出到同一个文件夹时,上次清单里有、这次没有的文件会被删掉(removed 是删掉的文件名),清单以外的文件不碰。文件名必须是单纯的文件名,否则整次导出报错、一个文件也不写。
Inputs: saved_as (required), out_dir.
find_instancesB
按名称或编号找数据里的某个对象(实例图谱的起点),给出节点 id;对象类型没有名称字段时 name 就是识别值。
Inputs: type (required), saved_as (required), query.
find_name_variantsA
找出同一类对象里可能是同一个东西的不同写法,只给建议、不合并。会调用模型。
Inputs: saved_as (required).
fix_questionA
把问过的一道题固定为验收问题:以后重传同一份文件,用同一个查询再算一次。只在人明确说了之后调用。这道题的答案里有模型自己加的条件(evidence.filters 里 not_in_question、且筛掉了对象)时,note 不写就报错:先问人,不该加用 drop_filter 去掉重算,该加就在 note 里写明口径。
Inputs: question (required), saved_as (required), note.
get_cardA
一次运行的口径卡(数据是什么意思):每张表一行是什么、日期列的最早最晚和空值、数值列的类型,以及已答复的格(answer:value、says、by、basis、at)和对象全不全。代码能算的已经算好,只有人能答的留空;blank 是还没说清的格数。文档运行没有卡,返回空的 tables。格的 value 只能是下面的值,种类看 id 冒号前的那段,等号后是意思:grain(一行是什么):one_object=一行就是一个对象、event=一行是一次事件或一次修改(同一个东西有多行)、period=一行是一段时期的汇总、unsure=说不清;date(日期列是什么时间):business=业务发生的日期、system=系统录入或修改的时间、fetched=取数的时间、unsure=说不清;amount(数值列能不能加):flow=每行是这一笔自己的数,可以跨行相加、running=每次事件后的累计值、latest=截至最近一次的值、period_to_date=期初到期末的累计值、not_amount=不是数量(编号或代码)、unsure=说不清;complete(对象全不全):full=数据里是全的、partial=数据里只有一部分、unsure=说不清。日期范围格 range 的 value 写 {"from": "YYYY-MM-DD" 或 null, "to": "YYYY-MM-DD" 或 null}。
Inputs: saved_as (required).
healthA
本机建模服务是否在跑、有没有模型凭据、是否在跑旧代码。
Inputs: no named parameters.
instance_neighbourhoodB
实例图谱:一个对象的字段,和数据里与它相连的对象;每条关系先给 20 个,其余计数。
Inputs: node (required), saved_as (required).
list_objectsA
本体里的对象:名称、说明、来自哪些表、识别字段、数据里有多少个、几条关系、人的判断。人判错的默认不给,列在 left_out 里;include_wrong=true 全给。
Inputs: saved_as (required), include_wrong.
list_questionsA
这次运行里模型出的题(model_round)、人问过的题(asked)和固定的验收问题(acceptance),带答案和查询路径。每道题有 status:answered 答出来了;no_data 数据里没有满足条件的对象;query_limit 查询写不出来、ontology_gap 本体缺回答它要的东西(reason_from_model 为 true 时是模型的判断;否则是代码查出来的原因,照 reason 告诉人);needs_derived 要一个派生指标,derive 里是公式和试算,人同意后才 confirm_derived。evidence 是代码给的核对依据:filters 是查询里的筛选条件(before、after 是筛前筛后的对象数,removed_measure 是筛掉的那部分的合计),其中 not_in_question 的是模型自己加的、题目没提,该不该加由人定,不加用 drop_filter 去掉重算;merged 是被算成同一个的对象组(同一个名字下有几个不同的识别值);found_elsewhere 是 no_data 时,这个值在别的对象里能找到的地方。口径卡:refused_by_card 是被卡上的哪一格拒答的(status 是 query_limit,reason 是代码给的),照 reason 告诉人,不要换问法绕过;evidence.card 是答案用了哪张表、数据到哪天(tables)、按哪几条口径(lines),incomplete 是对象在数据里只有一部分,要转告人。
Inputs: saved_as (required).
list_relationsA
本体里的关系:两端、含义、来源表、基数、人的判断。cardinality 是 one_to_one / one_to_many / many_to_one / many_to_many,方向是 from 到 to;reads 用两端对象的名字把它读成一句中文,most_from 是一个 from 对象最多对应几个 to,most_to 是一个 to 对象最多对应几个 from。判错的、或一端对象判错的默认不给,列在 left_out 里;include_wrong=true 全给。
Inputs: saved_as (required), include_wrong.
list_rulesB
代码在数据里找到的规则(某字段每个对象都有值;两个日期总是先后有序)和人采纳的规则,采纳的带本次数据里的违反数和例子。
Inputs: saved_as (required).
list_runsB
本机保存过的运行,新的在前。
Inputs: limit.
object_fieldsC
一个对象的属性:每个字段的类型、长度、空值和来源表(交接到数据平台时要填的列)。
Inputs: type (required), saved_as (required).
object_rowsB
一个对象在数据里的每一个实例,一页 20 个;all=true 一次给全部。
Inputs: type (required), saved_as (required), all, page.
preview_uploadA
不调用模型:看这几份文件会发给模型什么(字段名、示例值、代码在全部行上数出的计数、每行都不同的列和可能的连接)。
Inputs: files (required), purpose.
run_overviewA
一次运行的概况:对象和关系数、体检通过几项、问答能答几道、稳定性、是否确认过;open_items 是要和客户确认的事(服务算好的清单,每项有 kind、ask、facts、from_model、target),先看它,是要带给人的事。answered_items 是已记下客户答复的事,card 是口径卡的格数 {cells, blank}(blank 是还没说清的格,看细节用 get_card)。服务是旧版本、没有这个清单时 open_items、answered_items 为 null,note 里说明;card 只有在旧版服务没有这条路由时才是 null,没有数据行的运行(文档、没通过核验)给 {cells:0, blank:0}。文档运行没有要和客户确认的事,也不会去请求这份清单和口径卡:open_items、answered_items 直接给 []。
Inputs: saved_as (required).
save_cardA
记下客户对口径卡的答复,也可以记下“要确认的事”里能答复的事的答复。只记人说的客户答复:by(答复人)和 basis(出处)都来自人,不要自己填格,不要替客户答,不要按列名猜;只在人明确说了之后调用。校验不过整次不写,服务的说明原样返回。cells 每项 {id, value, note?, basis?}:id 来自 get_card,value 是那一格可选的值,null 表示清空。格的 value 只能是下面的值,种类看 id 冒号前的那段,等号后是意思:grain(一行是什么):one_object=一行就是一个对象、event=一行是一次事件或一次修改(同一个东西有多行)、period=一行是一段时期的汇总、unsure=说不清;date(日期列是什么时间):business=业务发生的日期、system=系统录入或修改的时间、fetched=取数的时间、unsure=说不清;amount(数值列能不能加):flow=每行是这一笔自己的数,可以跨行相加、running=每次事件后的累计值、latest=截至最近一次的值、period_to_date=期初到期末的累计值、not_amount=不是数量(编号或代码)、unsure=说不清;complete(对象全不全):full=数据里是全的、partial=数据里只有一部分、unsure=说不清。日期范围格 range 的 value 写 {"from": "YYYY-MM-DD" 或 null, "to": "YYYY-MM-DD" 或 null}。items 每项 {id, choice?, text?, basis?}:id 来自 run_overview 的 open_items,choice 的可选值看事的种类(unlinked:expected、incomplete;same_name、merged:distinct、same),没有 choice 时 text 必填。unlinked 答“数据没导全”(incomplete)时,服务会自动把另一端对象在卡上记成“只有一部分”,改答复时撤回,不用另发那一格。cells 和 items 至少给一样。写完返回 {card, items, answered}。
Inputs: by (required), saved_as (required), cells, items.
save_formB
保存对象表单。form 形如 {"types": {"<对象key>": {"label": "中文名", "description": "描述", "display_field": "字段", "drafted": false, "fields": {"<字段>": {"label": "…", "description": "…", "drafted": false}}}}};drafted=false 表示人写的。
Inputs: form (required), saved_as (required).
set_rulesA
采纳或不要规则:adopted、declined 各写完整的规则 id 列表(id 来自 list_rules)。采纳的规则以后每次重跑都会检查。
Inputs: adopted (required), saved_as (required), declined.
suggest_relationsB
代码在数据里看到、本体里没有的关系,只作建议:同一行上的两个对象没连起来;某列写的是别的对象的名称(且指向的不是本行已连着的那个);或某列按名字和取值指向别的对象的编号。
Inputs: saved_as (required).
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 32 tools
Most tools have sharply distinct roles (build vs inspect vs answer vs export), and the verbose Chinese descriptions spell out preconditions and return shapes. A few pairs could still be confused: find_instances vs object_rows (lookup by name vs enumerate all instances), and the ask_question / list_questions / fix_question / drop_filter cluster requires careful reading to pick correctly.
Everything is uniformly snake_case and most names follow verb_noun (find_instances, list_objects, save_card, set_rules, build_ontology, export_ttl). The deviations are noun-only names like health, data_check, data_layout, object_rows, run_overview, which form a recognizable secondary pattern rather than random mixing.
32 tools is heavy for one server, and there is clear bloat: the four export_* tools repeat an identical ~200-character paragraph about out_dir, manifest files and overwrite semantics, and card/question tooling is split across many narrow operations. The multi-phase workflow (ingest, model, verify, answer, export) justifies breadth, but the surface should be consolidated.
The surface covers the full lifecycle: preview upload, build ontology, health-check data, confirm types/relations/rules, answer questions with derived-metric approval, record customer answers, and export to CSV/Mermaid/Turtle/pipeline spec. Minor gaps: no way to delete or re-run a stored run, and instance-level data export beyond per-object forms is absent.
Maintenance
Related MCP Connectors
Universal Document Intelligence: 70+ formats & 75+ languages to LPG/RDF entities & tables (13 tools)
Enterprise memory, search, and context for frontier AI. 38 tools for business intelligence.
Ontology platform for field service: AI agents observe, connect and act on business objects.
Bi-temporal AI memory. 56 tools, knowledge graph, semantic search. EU-hosted, free tier.
Related MCP Servers
- AlicenseNot gradedqualityNot gradedmaintenanceEnables AI assistants to navigate and populate complex ontologies by transforming unstructured data into structured, SHACL-validated knowledge graphs. It features semantic hybrid search and proactive schema guidance to help users build deeply linked, reasoning-ready data.-
- AlicenseAqualityCmaintenanceEnables AI assistants to query, modify, and reason over OWL/TTL/RDF ontology files using natural language, without needing SPARQL or OWL syntax.146MIT
- AlicenseNot gradedqualityBmaintenanceExposes Iceberg-backed ontology objects, links, and actions as typed MCP tools for LLM agents, enabling governed data access and operations without raw SQL.MIT
- AlicenseCqualityBmaintenanceReference implementation of the Operational Ontology pattern: MCP tools are generated from a typed business domain model (objects, links, actions) — one tool per query shape and per action, deliberately no raw SQL tool. Writes pass business-rule preconditions, are audited, and write back to the systems of record; refusals are machine-readable. Ships with a demo orders ontology spanning two legacy34210MIT