plctap
PYPI · PLCTAP · SCANNED SEP 20
Agent-PLC MCP Server: read & diagnose Modbus / FINS / MELSEC / S7 / IEC 104 / ENIP / OPC UA PLCs.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security50
- Malware scan not yet available for this package.Unverified
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
- 4 of 50 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency32
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: the license (MIT License) isn't a recognized OSI-approved license. See how to fix → Fail
- Actively maintained (last published 6 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability59
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 3096 tokens (~206/item across 15 items; 15 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management47
- Stability observed for 14 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 15 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 16 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
How do I install the plctap MCP server?
plctap runs locally as a PyPI package, launched with uvx plctap. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · plctap
claude mcp add ymxc152-plctap -- uvx plctap
{
"mcpServers": {
"ymxc152-plctap": {
"command": "uvx",
"args": [
"plctap"
]
}
}
} {
"servers": {
"ymxc152-plctap": {
"command": "uvx",
"args": [
"plctap"
]
}
}
} codex mcp add ymxc152-plctap -- uvx plctap
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"ymxc152-plctap": {
"type": "local",
"command": [
"uvx",
"plctap"
],
"enabled": true
}
}
} openclaw mcp add ymxc152-plctap --command uvx --arg plctap
mcp_servers:
ymxc152-plctap:
command: "uvx"
args: ["plctap"] {
"McpServers": {
"ymxc152-plctap": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"plctap"
]
}
}
} assistant mcp add ymxc152-plctap -t stdio -c uvx -a plctap
{
"mcpServers": {
"ymxc152-plctap": {
"command": "uvx",
"args": [
"plctap"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 19 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 40 to 43. That category is still filling its 30-day observation window: 12 days of observed history at the previous scan, 13 at this one. The score rises as the window fills, whether or not the server changes.
- 17 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.
- 15 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes.
- 13 Sept 26 +1
- Malware scan: unverified → pass ▲ security
- Package version: 0.6.1 → 0.6.2 functional
- 11 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.
- 9 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.
- 8 Sept 26 −16
- Malware scan: pass → unverified ▼ security
- Schema quality: 185 → 206 ▼ functional
- Schema quality: 2591 → 3014 ▼ functional
- Package version: 0.5.5 → 0.6.1 functional
- Package version: 0.5.5 → 0.6.0 functional
- 7 Sept 26 +15
- Malware scan: unverified → pass ▲ security
- Stability: unverified → 0.03 ▲ functional
- Schema quality: excellent → good functional
- Package version: 0.4.0 → 0.5.5 functional
- Package version: 0.4.0 → 0.5.4 functional
- Package version: 0.4.0 → 0.5.2 functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Analysed pypi/plctap@0.6.2
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 50 packages
| Packages resolved | 50 |
|---|---|
| Stale | 3 |
| No linked repository | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
detect_device Detect Device ~328
设备自动识别: 给定 host 自动扫端口并判定协议 (v0.4, 全程只读)。 流程: 并发扫描候选端口 (缺省 102/502/2000/2404/44818/4840/5007/6000/9600/9601, 单端口连接预算 0.5s) -> 开放端口并发跑已注册协议 probe 指纹 (单协议预算 timeout_ms/1000, 缺省 0.8s; 个别协议有独立预算如 opcua 的完整会话握手) -> high 候选按协议做一次最小读验证 (deep=True 缺省; 成功升级 verified, 失败留痕保持 high; deep=False 跳过验证读)。 只读保证: 全程只发握手帧 + 最小读帧, 不写任何数据; 且识别 ≠ 可访问 —— 例如 S7 PUT/GET 被关闭时识别照样成功, 读 DB 仍可能失败。 返回 DetectResult: candidates 按置信度降序 (同级先验匹配端口优先, next_step 可直接作为 plc_read 调用), unknown_services 为开放但 已注册协议都不认识的端口 (可用 start_listener 钓帧分析)。
| Name | Type | Req | Description |
|---|---|---|---|
| deep | boolean | – | – |
| host | string | yes | – |
| ports | – | – | – |
| timeout_ms | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| candidates | array | yes | – |
| closed_count | integer | yes | – |
| elapsed_ms | integer | yes | – |
| host | string | yes | – |
| network_assessment | string | yes | – |
| open_ports | array | yes | – |
| scanned_ports | array | yes | – |
| unknown_services | array | yes | – |
No examples provided.
diagnose Diagnose ~217
综合观测给出结构化的故障候选结论 (确定性规则, 不编故事; 全程只读)。 三种证据可任意组合 (至少给一种): - frame_hex: 一帧报文 hex (解析 + 校验 + 规则匹配) - log_snippet: 通信日志文本, 自动提取其中的 hex 帧逐帧解析 - host + port: 连上设备做一次探测, 把探测归因纳入推理 返回 DiagnosticReport: candidates 按 confidence 降序, 每条含 symptom/root_cause/evidence(证据链)/suggested_action/next_tools; evidence 与 observations 保留原始观测供复核。空 candidates = 知识库未覆盖, 不硬凑结论。
| Name | Type | Req | Description |
|---|---|---|---|
| frame_hex | – | – | – |
| host | – | – | – |
| log_snippet | – | – | – |
| port | – | – | – |
| protocol | string | yes | – |
| unit | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| candidates | array | – | – |
| next_tools | array | – | – |
| observations | array | – | – |
No examples provided.
get_listener_frames Get Listener Frames ~97
取监听收下的帧 (direction/peer/frame_hex), 供 parse_frame/diagnose 分析。 取最新 limit 条; 环形缓冲硬上限 1000 条 (limit 超限自动截到缓冲 大小, limit<=0 返回空) —— 输出量受 limit 与缓冲上限双重约束。
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| port | integer | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
get_proxy_frames Get Proxy Frames ~93
取代理录制的双向透传帧 (direction: c2s=上位机→PLC, s2c=PLC→上位机)。 取最新 limit 条; 环形缓冲硬上限 1000 条 (limit 超限自动截到缓冲 大小, limit<=0 返回空)。
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| port | integer | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
list_protocols List Protocols ~84
列出本 server 支持的工业协议及其能力。 返回每个协议的端口提示、地址模型、数据类型和品牌线索, Agent 可据此推断 "这个设备该用什么协议" 而无需问用户。 不确定协议名时先调用本工具。 不确定协议/端口时先调用 detect_device。
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| allow_write | boolean | yes | – |
| hint | string | yes | – |
| protocols | object | yes | – |
No examples provided.
parse_frame Parse Frame ~376
把一帧报文 hex 逐字段结构化解析 (不需要连接设备)。 每个字段带 byte_offset 与 raw_hex 证据; 支持正常请求/响应与异常 响应帧; 畸形帧不抛错, 而是尽量解析并在 errors 里说明哪里坏 —— "解析失败的方式"本身是诊断证据。 direction: "auto" 按帧结构判别, 也可显式传 "req" / "resp"。 frame_format (仅 melsec): "3e_binary" / "3e_ascii" / "4e_binary" / "4e_ascii"。 - modbus: 异常帧/非 12 字节按响应, 12 字节按请求 (fc05/06 的响应 与请求逐字节相同, 任一解释一致) - fins: TCP 命令 0x00 按请求 / 0x01、0x02 按响应; 0x04 按 FINS ICF bit6 判别 (响应置位) - melsec: 副头部 50 00/54 00 按请求, D0 00/D4 00 按响应 (ASCII 帧 "5000"/"5400"/"D000"/"D400" 同理) - s7: rosctr=0x01 (Job) 按请求, 0x03 (Ack_Data) 按响应; 显式传 direction 时按传入值
| Name | Type | Req | Description |
|---|---|---|---|
| direction | string | – | – |
| frame_format | string | – | – |
| frame_hex | string | yes | – |
| protocol | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| direction | string | yes | – |
| errors | array | – | – |
| fields | array | – | – |
| protocol | string | yes | – |
| valid | boolean | – | – |
No examples provided.
parse_pcap Parse Pcap ~222
解析 Wireshark 导出 pcap: 按 TCP 流聚合载荷 -> 按协议切帧 -> 逐帧 parse_auto。 每个流返回完整帧序列 (带结构化解析) 与尾部半帧 (partial, 截断也是 诊断信息)。protocol 缺省时按"完整帧数最多的协议"自动判别。 需要可选依赖 scapy (uv sync --extra eval)。大批量帧场景比逐条 frame_hex 高效得多。 输出受 64KB token 预算约束: 超出时按流序/帧序装帧并截断, 末尾追加 一条 flow 以 "truncated:" 开头的 sentinel 流 (frames 为空, 带 total/shown 计数)。需要其余帧时用 protocol= 过滤或拆分 pcap 再解析。
| Name | Type | Req | Description |
|---|---|---|---|
| path | string | yes | – |
| protocol | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
plc_browse Plc Browse ~239
浏览地址空间: 从 node 展开一层子节点 (诊断场景的"列目录")。 返回 {node, children, total, shown, truncated}: children 每项含 node_id / display_name / node_class; 超出输出预算时 truncated=true 且 total 给出全量数 —— 需要更深层级就对着子 node_id 再调一次。 默认从 Objects 文件夹 (ns=0;i=85) 起步; 对 plc_read 前先摸清 设备地址空间结构时用。 当前仅 OPC UA 支持 (会话协议无帧概念, browse 是它的"读目录"形态); 其他协议用 list_protocols 的 read_options 直接构造地址。 输出预算: 单次最多 200 个子节点 (约 30KB), 防止大地址空间撑爆上下文。
| Name | Type | Req | Description |
|---|---|---|---|
| host | string | yes | – |
| limit | integer | – | – |
| node | string | – | – |
| port | integer | yes | – |
| protocol | string | yes | – |
| timeout_ms | – | – | – |
| unit | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| children | array | – | – |
| node | string | yes | – |
| shown | integer | yes | – |
| total | integer | yes | – |
| truncated | boolean | yes | – |
No examples provided.
plc_read Plc Read ~378
从 PLC 读取数据区并按数据类型解释。 address/count 为通用地址与数量, 语义由协议决定: - Modbus: address 为 0 基寄存器地址, count 为寄存器个数 - FINS: address 为字地址, count 为字数 - MELSEC: address 为起始编号, count 为点数 (位软元件按 16 点/字) - S7: address 为字节地址, count 为**字节数** (count=4 + uint16 → 2 个值) - EtherNet/IP: address 为 tag 名字符串 (如 "alpha[0]"), count 为元素个数 - OPC UA: address 为 NodeId 字符串 (如 "ns=2;i=5" / "ns=2;s=Demo.Double"), count 为数组节点返回元素上限 (0=全部); 值按 UA 内建类型原生返回 datatype 取 uint16/int16/float32, None 返回原始 16 位值 + 所有常见数据类型的多解释 (interpretations 字段), 便于 Agent 识别正确的数据类型。 byteorder 仅影响 float32 寄存器对顺序 (big=ABCD, little=DCBA)。 options: 协议特有参数, 由各协议 adapter 自行定义与校验。 用 list_protocols 查看每个协议的 read_options 说明。
| Name | Type | Req | Description |
|---|---|---|---|
| address | – | yes | – |
| byteorder | string | – | – |
| count | integer | – | – |
| datatype | – | – | – |
| host | string | yes | – |
| options | – | – | – |
| port | integer | yes | – |
| protocol | string | yes | – |
| timeout_ms | – | – | – |
| unit | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| address | – | yes | – |
| elapsed_ms | integer | yes | – |
| interpretations | – | – | – |
| interpreted | – | – | – |
| raw_registers | array | yes | – |
| request_frame | string | yes | – |
| target | object | yes | 目标设备标识, 同时是连接池 key 的组成部分 (D1)。 |
No examples provided.
probe_device Probe Device ~194
测试能否连上 PLC 并通信, 失败时给出层级归因。 reachable = 传输层可达 (TCP 已建立; 设备回异常响应也算在线)。 failure_class 取: - connection_refused: 端口没人监听/网络不可达 (查网络与端口) - timeout: 连接超时 (查网络路由/防火墙) - connected_but_no_reply: TCP 通了但设备不回话 (查协议配置) - exception_response: 设备回异常码 (查 unit/寄存器配置, 带 exception_code) 典型用法: 设备"读不到数据"时先调本工具分层定位, 再决定下一步。
| Name | Type | Req | Description |
|---|---|---|---|
| host | string | yes | – |
| port | integer | yes | – |
| protocol | string | yes | – |
| unit | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| exception_code | – | – | – |
| failure_class | – | – | – |
| identity | – | – | – |
| layer_hint | string | – | – |
| reachable | boolean | yes | – |
No examples provided.
start_listener Start Listener ~264
起钓鱼模式监听: 待测设备只能当 client 时, 立假 server 钓出它的帧行为。 mode 三档: record_only=只收帧不回复 (纯被动) / respond_normal=对读类 请求回最小"正常响应" (数据恒 0, 目的只是让设备继续吐帧, 非通用模拟器) / inject_errors=正常回帧但按 faults 列表轮转注入确定性故障 (评测语料 生产 + 诊断引擎回归)。 faults (仅 inject_errors): modbus 可选 exception/bad_length/truncate, fins/melsec 可选 end_code/bad_length, 全协议通用 garbage。 收下的帧用 get_listener_frames 取, 再喂 parse_frame/diagnose。 port=0 由系统分配, 返回实际端口。建议收满样本后 stop_listener, 并提醒用户恢复设备原配置。
| Name | Type | Req | Description |
|---|---|---|---|
| faults | – | – | – |
| host | string | – | – |
| idle_timeout_sec | integer | – | – |
| mode | string | – | – |
| port | integer | – | – |
| protocol | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| faults | array | – | – |
| host | string | yes | – |
| mode | string | yes | – |
| port | integer | yes | – |
| protocol | string | yes | – |
| recorded | integer | yes | – |
| status | string | yes | – |
No examples provided.
start_proxy Start Proxy ~187
起透明代理: 上位机 → 代理 → 真实 PLC, 透传同时按协议分帧录制双向帧。 现场联调时把上位机目标地址改成本代理, 无需 Wireshark 即可拿到全部 交互帧 (get_proxy_frames), 再喂 parse_frame/diagnose 做在线分析。 protocol 当前支持 modbus/fins/melsec (S7 TPKT 分帧暂不支持); listen_port=0 由系统分配。代理是诊断设施: 只透传与录制, 不改写帧。
| Name | Type | Req | Description |
|---|---|---|---|
| idle_timeout_sec | integer | – | – |
| listen_host | string | – | – |
| listen_port | integer | – | – |
| protocol | string | yes | – |
| target_host | string | yes | – |
| target_port | integer | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| hint | string | yes | – |
| listen_port | integer | yes | – |
| protocol | string | yes | – |
| recorded | integer | yes | – |
| status | string | yes | – |
| target | string | yes | – |
No examples provided.
stop_listener Stop Listener ~32
停掉指定端口的监听, 返回收/发帧统计。
| Name | Type | Req | Description |
|---|---|---|---|
| port | integer | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| mode | string | yes | – |
| port | integer | yes | – |
| recorded | integer | yes | – |
| sent | integer | yes | – |
| status | string | yes | – |
No examples provided.
stop_proxy Stop Proxy ~40
停掉指定端口的代理, 返回录制统计 (c2s/s2c 帧数)。
| Name | Type | Req | Description |
|---|---|---|---|
| port | integer | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| c2s | integer | yes | – |
| port | integer | yes | – |
| recorded | integer | yes | – |
| s2c | integer | yes | – |
| status | string | yes | – |
| target | string | yes | – |
No examples provided.
validate_frame Validate Frame ~186
对一帧报文跑规范校验清单, 逐项 pass/fail (不需要连接设备)。 Modbus TCP: MBAP 长度一致性、协议号、功能码、unit 范围、PDU 自洽、数量/地址边界、异常码 (Modbus TCP 无 CRC, RTU 才有)。 FINS/TCP: magic、TCP 长度自洽、TCP 命令合法、error 字段、 FINS 端结码、载荷完整性。 MELSEC 3E: 副头部、数据长度自洽、命令/软元件代码、结束代码。 direction 取 req 或 resp。
| Name | Type | Req | Description |
|---|---|---|---|
| direction | string | – | – |
| frame_format | string | – | – |
| frame_hex | string | yes | – |
| protocol | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
What is the plctap MCP server?
plctap is an MCP server listed in the public MCP registry as io.github.ymxc152/plctap. Agent-PLC MCP Server: read & diagnose Modbus / FINS / MELSEC / S7 / IEC 104 / ENIP / OPC UA PLCs. This page covers its PyPI package (plctap).
Is the plctap MCP server safe to use?
plctap scores 54 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the plctap MCP server expose?
plctap exposes 15 tools: list_protocols, probe_device, plc_read, plc_browse, diagnose, and 10 more. Their descriptions and schemas cost roughly 2,937 tokens of context every time the server is loaded.
Is the plctap MCP server still maintained?
plctap is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.