
plctap
io.github.ymxc152由 GitHub 帳號 ymxc152 發布v0.6.2更新於 Oct 24, 2026
Agent-PLC MCP Server: read & diagnose Modbus / FINS / MELSEC / S7 / IEC 104 / ENIP / OPC UA PLCs.
概覽
本機 MCP 伺服器,讓助理連線、讀取、診斷並可選擇寫入 Modbus、FINS、MELSEC、S7、IEC 104、EtherNet/IP 與 OPC UA 工業 PLC。
- 可以做什麼
- 探測與辨識裝置:自動判定主機上的協定、檢查連通性並分層歸因失敗,瀏覽 OPC UA 位址空間,列出支援的協定與其定址模型。讀取八個協定端點的 PLC 資料區,並依資料型別與位元組順序解讀數值。診斷:解析與驗證單一訊框、對日誌執行規則引擎診斷、解析 Wireshark 匯出的 pcap。擷取流量:以假伺服器監聽並可選擇注入錯誤,或用透明代理錄製雙向訊框。寫入與傳送:僅在開啟寫入閘門後註冊寫暫存器與傳送原始訊框的工具,並逐訊框記錄稽核日誌。
- 適用情境
- 適合工業設備的現場診斷與調試:判斷裝置使用何種協定、確認可達性、將讀值與上位機顯示比對,並把擷取到的訊框或日誌轉成結構化結論。也適合透過監聽器的錯誤注入對上位機容錯能力做回歸測試。
- 執行需求
- 以 stdio 本機程序執行,透過 uvx 或 pipx 安裝(Python)。需要能存取 PLC 或閘道主機及其連接埠。選用環境變數:PLCTAP_ALLOW_WRITE(預設 false)、PLCTAP_DEFAULT_TIMEOUT_MS、PLCTAP_POOL_MAX_PER_TARGET、PLCTAP_IDLE_TIMEOUT_SEC、PLCTAP_AUDIT_LOG。解析 pcap 需安裝 eval 附加相依套件。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 plctap,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
plctap
中文 | English
Agent 的 PLC 驱动层 — 让 Claude / Codex / Cursor 直接连接、读写、诊断 Modbus TCP / Modbus RTU over TCP / FINS / MELSEC / Siemens S7comm / IEC 60870-5-104 / EtherNet/IP (CIP) 设备的 MCP Server。
[CI] [PyPI] [MCP Registry] [License: MIT]
状态: v0.6 (协议自动识别 + 透明代理 + 故障注入监听 + 八协议端点接入 (含 OPC UA 连接级诊断), 六端点可写 (IEC 104 / OPC UA 仅读); IEC 104 经 lib60870、EtherNet/IP 经 pycomm3 官方实现交叉验证, OPC UA 为 asyncua 官方库台架自洽验证)。
工具
全部工具带 MCP annotations hint (wire 逐键锁定于 tests/test_tool_annotations.py): 纯本地解析类
readOnlyHint=true / openWorldHint=false, 联网读/探测/取帧类 readOnlyHint=true, 监听/代理
启停为非只读状态变更 (非破坏、非幂等), 写类 destructiveHint=true 且默认不注册 —— 客户端可
据此判断并行安全性与调用前确认级别。
写能力
PLCTAP_ALLOW_WRITE=true 后八端点中六个可写 (modbus_rtu 与 modbus 同轨同语义; iec104 与 opcua 仅读):
所有写/发送动作逐帧写入审计日志 (发送前留痕, 失败也留)。
协议速查
八个端点的寻址模型与常用参数 (接入前先对表; 工具内 list_protocols 亦可动态获取):
datatype 支持 uint16 / int16 / float32 / int32; byteorder 仅影响 float32 的寄存器对顺序
(big=ABCD, little=DCBA)。datatype 缺省时返回全部常见类型 × 字序的多解释, 字序存疑时直接比对。
示例调用 (客户端中按参数填写):
modbus 与 modbus_rtu 怎么选: 网关/上位机已封装 MBAP 头 (标准 Modbus TCP) → modbus;
串口服务器或网关工作在 RTU 透传模式 (TCP 上是裸 RTU 帧) → modbus_rtu。
典型工作流 (现场诊断)
detect_device(host=...)— 不知道对面是什么: 并发探测标准端口, 按响应指纹判定协议/端口/置信度, 返回可直接执行的plc_read建议 (全程只读)。probe_device(protocol, host, port)— 连通性确认; 失败时四类分层归因 (connection_refused / timeout / connected_but_no_reply / exception_response), 直接告诉您该查网络路由还是查协议配置 (IEC 104 为 STARTDT+TESTFR 握手探测)。plc_read(...)— 按「协议速查」读数, 与上位机显示或预期值比对。- 读数不对 / 通信故障 → 抓包帧喂
parse_frame/validate_frame做结构化解析与规范校验; 日志文本喂diagnose得到带证据链的结构化候选结论。 - 要看上位机 ↔ PLC 全部交互 →
start_proxy透明代理 (上位机改指向代理即可, 免 Wireshark); 设备只能当 client 主动外连 →start_listener假 server 钓帧, 支持inject_errors故障注入档做上位机容错回归。
快速开始
已收录于 MCP 官方 Registry: io.github.ymxc152/plctap
(支持按名称检索与安装的客户端可直接发现本服务)。
Claude Desktop 接入 (claude_desktop_config.json)
本地开发 (仓库检出路径):
Codex 接入 (~/.codex/config.toml)
配置 (环境变量, 均有默认值)
安全
- 写操作默认完全不注册; 显式
PLCTAP_ALLOW_WRITE=true才启用。 - 所有写/发送动作逐条写入 JSONL 审计日志 (
~/.plctap/audit.jsonl, 不可关)。 - 发送类调用请配合客户端审批弹窗使用 (用户可见目标 IP 与完整帧)。
- 审计日志样例:
{"ts":"2026-09-04T01:20:33+0800","tool":"plc_write","target":"modbus://127.0.0.1:15020 unit=1","frame_hex":"0002000000060106000104d2","caller":"mcp"}
开发
质量保障
- 569 项测试(codec 纯函数 + 适配器(含 Modbus RTU / IEC 104 / EtherNet/IP / OPC UA)+ 诊断引擎 + 监听器 + 透明代理 + detect_device + MCP 冒烟),CI 每次推送回归。
- 跨厂商 e2e(tests/e2e):plctap 与 pymodbus、python-snap7、
pymcprotocol、pypi fins、MZ Automation 官方 lib60870.NET、pycomm3(Rockwell 官方客户端库)六个第三方权威实现做真实 socket 交叉验证
(读写闭环、读数逐值比对、钓鱼监听互通),CI 随行(
uv sync --group e2e); IEC 104 交叉验证需 .NET 8 SDK(缺省自动跳过)。OPC UA 端点为 asyncua 官方库 + 台架自洽验证(会话协议无帧级诊断,与本节其余端点的字节级交叉验证口径不同,如实区分)。 - 八档评测 49/49:单帧 / RTU 完整性 / 批量日志 / FINS·MELSEC 专项 / 主动探测归因 / 协议自动识别 / IEC 104 专项 / EtherNet/IP 专项 (detect 档含"回显服务器欺骗"与"证据压过端口先验"两类反例);与裸模型的双跑对比见下节。
评测对比 (裸模型基线双跑: 五档 35 用例)
* 同一批语料双跑, 除工具外一切相同: 裸模型 (glm-5.3-flash, 无工具, temperature=0) 直接问答; 确定性关键词判分 (事实等价集, 双模式共用); 6 例因推理端点超时未获有效答案计 FAIL (排除超时后 24/29 = 82.8%)。裸模型跑分日期 2026-09-04, 语料版本 317e868 (跑分时点; fins 语料其后于 b319374 随线上格式修正同步更新, 判分语义不变)。 范围说明: 语料建于 M2 (v0.2 时代), 覆盖帧解析 / CRC 完整性 / 日志混排 / 冷门协议语义 / 主动探测归因; v0.3+ 功能 (plc_write / parse_pcap / 透明代理 / modbus_rtu 端点 / vendor_hints / iec104 端点 / enip 端点 / opcua 端点) 未纳入基线。detect 档 (4 用例, v0.4 新增)、iec104 档 (6 用例, v0.5.2 新增) 与 enip 档 (4 用例, v0.5.3 新增) 需起真实网络服务/台架做主动探测与交互, 不适合裸问答 形式, 故未纳入对比 —— 工具模式八档合计 49/49 (2026-09-07 按当前语料复跑, 见「质量保障」)。 结论: 单帧翻译裸模型已能胜任, 价值差距集中在冷门协议语义与多故障混排场景 —— 这正是确定性解析 + 结构化知识库的所在。方法学与复跑步骤见 eval/README.md。
运行时边界: eval/ 是开发期基准测试 harness (裸模型基线对比), 仅复跑评测时需要
PLCTAP_ 前缀环境变量 (key/端点/模型全部显式提供, 仓库不内置任何厂商端点);
发布产物只含 src/plctap —— MCP server 运行时零 AI/LLM 依赖,
不读也不需要任何模型 API 凭据。
多模型裸基线矩阵 (2026-09-08: 4 模型 × 双跑 × 五档 35 用例)
换任何裸模型 (弱/中/强/Agent 同款) 都在 8~13/35 徘徊, 冷门协议档 8 轮合计 0/96; 挂上 plctap 工具层后 49/49 (八档), 且与模型强弱无关。 两种失败模式同时被工具层免疫: 推理跑飞 (八轮 81 次零输出, 单例实测烧满 32768 reasoning tokens 无正文) 与 "流畅的错误" (deepseek-v4-flash 无答案仅 2/2 却总分最低, FINS/MELSEC 档 12 条全错)。
* 无答案 = 模型零输出 (推理超时), 计 FAIL (09-04 口径沿用)。本矩阵与上表 (2026-09-04, 24/35) 不可同表硬比: 端点不同 (火山方舟 vs Codex 本地代理)、服务端模型版本可能漂移、 判分等价集为当期校准 —— 同名模型 ≠ 同条件。双跑总分逐分复现 (temperature=0), 分档内部 有小幅漂移。完整矩阵与方法学见 eval/README.md。
版本与兼容承诺
自 v0.6.1 起遵循稳定化纪律:
- 向后兼容: MCP 工具名、参数名与各工具的返回结构保持兼容。返回结构由 pydantic 模型
定义并锁定 (
tests/test_tool_shapes.py黄金校验; 例外: list_protocols 的 protocols 条目为自由形态 dict); 新增协议端点、新增工具、新增可选参数只增不改。 - 工具 annotations: 17 个工具的 readOnlyHint/destructiveHint/idempotentHint/openWorldHint
四项全显式 (server.py
_ANN_*四分组), 黄金值锁定于tests/test_tool_annotations.py; annotations 属只增元数据, 任何取值变化按 wire 变化对待。 - 破坏性变更: 若不可避免, 在工具 docstring、本 README 与 Release notes 三处提前标注, 并尽量提供迁移期。
- 不承诺面:
src/plctap内部模块组织、诊断知识库条目数、评测数字随版本正常演进。 - 1.0 (语义定稿) 的宣布条件: 上述纪律经过至少一个完整发布周期的验证, 届时另行公告。
License
MIT
來源:README.md,提交 615b04d
工具
0版本歷史
1- v0.6.2最新Sep 16, 2026
評分
已滿足適用檢查項的 50%
該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。
- 近 30 天內可連通25 分
請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。
- 已宣告認證方式10 分
請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分