仓库：github.com/lkxlzx/StructAI-MCP-Server

MIDAS Open API 的**机器可读端点注册表（Endpoint Registry）**与配套开发文档、参考实现。

本仓库是 StructAI 多结构工程软件一体化 MCP（Model Context Protocol）Server 的知识层： 把 MIDAS 官方手册（Help Center JSON API、Civil NX 手册、Civil Designer 手册、GitHub 韩文整理版） 交叉合并为可直接被程序加载的 Registry，并用真实 MIDAS 实例逐端点实测验证。

---

0.🔴 会话边界（硬性原则）

一个批次 = 一个会话。

每完成 docs/07 §12 的一个批次（P01 / P02 / …），必须新建对话， 不得在同一窗口继续下一批 —— 否则上下文超长会稀释架构红线等早期约束。

• 完整规则 / 交接协议 / 批次状态表 / 可复制的续接提示词 → docs/08_会话交接与续接提示词_v1.0.md
• 每个新会话的第一个入口就是 docs/08;不要重读 docs/01–[06 全文（90.5 万字符）

---

目录

---

1.注册

字段与用法见 registry/README.md。

实测验证状态（availability）：verified 514 ·unverified 23 ·[untested 126。

⚠️ P176 / R168：verified +2（DOC.EXPORT / DOC.IMPORT 真机收口）·untested +27（「导出可见但未登记」的表补登，方法集未逐表实测 ⇒ 如实留在 untested）。

1.

StructAI MCP Server

仓库：github.com/lkxlzx/StructAI-MCP-Server

MIDAS Open API 的**机器可读端点注册表（Endpoint Registry）**与配套开发文档、参考实现。

本仓库是 StructAI 多结构工程软件一体化 MCP（Model Context Protocol）Server 的知识层： 把 MIDAS 官方手册（Help Center JSON API、Civil NX 手册、Civil Designer 手册、GitHub 韩文整理版） 交叉合并为可直接被程序加载的 Registry，并用真实 MIDAS 实例逐端点实测验证。

---

0. 🔴 会话边界（硬性原则）

一个批次 = 一个会话。

每完成 docs/07 §12 的一个批次（P01 / P02 / …），必须新建对话， 不得在同一窗口继续下一批 —— 否则上下文超长会稀释架构红线等早期约束。

• 完整规则 / 交接协议 / 批次状态表 / 可复制的续接提示词 → docs/08_会话交接与续接提示词_v1.0.md
• 每个新会话的第一个入口就是 docs/08；不要重读 docs/01–06 全文（90.5 万字符）

---

目录

registry/          Endpoint Registry（663 端点定义 + 652 JSON Schema + 索引 + 实例矩阵）
examples/          参考客户端与冒烟测试（midas_client.py / smoke_test.py / cases.json）
app/               Core 实现（P01 起逐步落地；进度见 docs/08 §3）
pyproject.toml     依赖与工具链配置（冻结于 docs/07 §3.1–§3.2）· .env.example 环境变量样例
docs/              V2 规范 01–06 + 通读报告 00 + 开发方案 07   ← 唯一开发依据
archive/legacy_v1/ 非规范性历史资料（V1 文档与实测留痕，不作依据）
MIDAS_API_*.md     MIDAS 官方手册整理（外部厂商资料）

---

1. Registry

字段与用法见 registry/README.md。

实测验证状态（availability）：verified 514 · unverified 23 · untested 126。

⚠️ P176 / R168：verified +2（DOC.EXPORT / DOC.IMPORT 真机收口）· untested +27（「导出可见但未登记」的表补登，方法集未逐表实测 ⇒ 如实留在 untested）。

1.1 主指标：接口层端到端（docs/07 §15.6.3）

⚠️ availability 是端点级、次指标。产品对外的单位是 Operation， 故主指标是接口层端到端与生产路径可用 Operation（docs/07 §15.6.3）。

证据 = registry/live/{interface_path_probe,interface_read_probe,flagship_chain_probe}.json； 生成器 = registry/tools/probe_interface_paths.py / probe_flagship_chain.py（均可 --check 离线复算）。

⚠️ R158（P165-b 更正）：主指标不再手写 —— 它由 python registry/tools/check_operation_availability.py --check 可执行复算。 旧值 62 / 71（「6 个端点 → 9 个 Operation」）是错的：它把 DESIGN.CODE_CHECK 算成可用，而该 Operation 的 7 条路由全部被挡（steel 的末步 POST.STEELCODECHECK 仍是 PARTIAL；concrete:* / src:* 需原生崩溃护栏拦住的 *-ANAL）。⇒ R158 的真实值 = 61 / 71、挡点端点 15 个。手写的指标必然漂。

⚠️ 上表「接口层读路径端到端」是 P153 的基线（在空专用项目上测得 ⇒ 取报表族