Plctap vs Next Devtools MCP
A side-by-side look at the Plctap and Next Devtools MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Plctap for industrial & iot work as a local process; choose Next Devtools MCP for developer tools as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Plctap when
- You need dedicated capabilities in the Industrial & IoT domain.
- You prefer a local stdio subprocess transport.
- You want tools like
list_protocols, probe_device, plc_read.
Choose Next Devtools MCP when
- You need dedicated capabilities in the Developer Tools domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
nextjs_index, nextjs_call, nextjs_docs.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Industrial & IoT | Developer Tools |
| Quality signal | 56/100 · Good | 86/100 · Excellent |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Free |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Verified |
| GitHub stars | 2 | 832 |
| Directory activity | 3 views 0 installs 0 upvotes | 9 views 0 installs 1 upvotes |
| Tools | 15 | 4 |
| Full listing | View Plctap | View Next Devtools MCP |
Tools & capabilities
Plctap tools 15
list_protocols列出本 server 支持的工业协议及其能力。 返回每个协议的端口提示、地址模型、数据类型和品牌线索, Agent 可据此推断 "这个设备该用什么协议" 而无需问用户。 不确定协议名时先调用本工具。 不确定协议/端口时先调用 detect_device。probe_device测试能否连上 PLC 并通信, 失败时给出层级归因。 reachable = 传输层可达 (TCP 已建立; 设备回异常响应也算在线)。 failure_class 取: - connection_refused: 端口没人监听/网络不可达 (查网络与端口) - timeout: 连接超时 (查网络路由/防火墙) - connected_but_no_reply: TCP 通了但设备不回话 (查协议配置) - exception_response: 设备回异常码 (查 unit/寄存器配置, 带 exception_code) 典型用法: 设备"读不到数据"时先调本工具分层定位, 再决定下一步。plc_read从 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 说明。plc_browse浏览地址空间: 从 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), 防止大地址空间撑爆上下文。diagnose综合观测给出结构化的故障候选结论 (确定性规则, 不编故事; 全程只读)。 三种证据可任意组合 (至少给一种): - frame_hex: 一帧报文 hex (解析 + 校验 + 规则匹配) - log_snippet: 通信日志文本, 自动提取其中的 hex 帧逐帧解析 - host + port: 连上设备做一次探测, 把探测归因纳入推理 返回 DiagnosticReport: candidates 按 confidence 降序, 每条含 symptom/root_cause/evidence(证据链)/suggested_action/next_tools; evidence 与 observations 保留原始观测供复核。空 candidates = 知识库未覆盖, 不硬凑结论。parse_frame把一帧报文 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 时按传入值validate_frame对一帧报文跑规范校验清单, 逐项 pass/fail (不需要连接设备)。 Modbus TCP: MBAP 长度一致性、协议号、功能码、unit 范围、PDU 自洽、数量/地址边界、异常码 (Modbus TCP 无 CRC, RTU 才有)。 FINS/TCP: magic、TCP 长度自洽、TCP 命令合法、error 字段、 FINS 端结码、载荷完整性。 MELSEC 3E: 副头部、数据长度自洽、命令/软元件代码、结束代码。 direction 取 req 或 resp。parse_pcap解析 Wireshark 导出 pcap: 按 TCP 流聚合载荷 -> 按协议切帧 -> 逐帧 parse_auto。 每个流返回完整帧序列 (带结构化解析) 与尾部半帧 (partial, 截断也是 诊断信息)。protocol 缺省时按"完整帧数最多的协议"自动判别。 需要可选依赖 scapy (uv sync --extra eval)。大批量帧场景比逐条 frame_hex 高效得多。 输出受 64KB token 预算约束: 超出时按流序/帧序装帧并截断, 末尾追加 一条 flow 以 "truncated:" 开头的 sentinel 流 (frames 为空, 带 total/shown 计数)。需要其余帧时用 protocol= 过滤或拆分 pcap 再解析。start_listener起钓鱼模式监听: 待测设备只能当 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, 并提醒用户恢复设备原配置。stop_listener停掉指定端口的监听, 返回收/发帧统计。get_listener_frames取监听收下的帧 (direction/peer/frame_hex), 供 parse_frame/diagnose 分析。 取最新 limit 条; 环形缓冲硬上限 1000 条 (limit 超限自动截到缓冲 大小, limit<=0 返回空) —— 输出量受 limit 与缓冲上限双重约束。start_proxy起透明代理: 上位机 → 代理 → 真实 PLC, 透传同时按协议分帧录制双向帧。 现场联调时把上位机目标地址改成本代理, 无需 Wireshark 即可拿到全部 交互帧 (get_proxy_frames), 再喂 parse_frame/diagnose 做在线分析。 protocol 当前支持 modbus/fins/melsec (S7 TPKT 分帧暂不支持); listen_port=0 由系统分配。代理是诊断设施: 只透传与录制, 不改写帧。- +3 more on the listing page
Next Devtools MCP tools 4
nextjs_indexDiscover running Next.js dev servers and list each one's runtime MCP tools.nextjs_callCall a runtime tool on a discovered server (errors, routes, logs, Server Actions).nextjs_docsGateway.** Point the agent at version-accurate docs in `node_modules/next/dist/docs/`.browser_evalGateway.** Point the agent at the [`agent-browser`](https://github.com/vercel-labs/agent-browser) CLI for browser automation.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Plctap
{
"mcpServers": {
"plctap": {
"command": "uvx",
"args": [
"plctap"
]
}
}
}
Next Devtools MCP
{
"mcpServers": {
"vercel-next-devtools-mcp": {
"command": "npx",
"args": [
"-y",
"next-devtools-mcp@latest"
]
}
}
}
Frequently asked questions
Plctap is categorized under Industrial & IoT and uses a local stdio subprocess. Next Devtools MCP belongs to Developer Tools and uses a local stdio subprocess. Pick Plctap for industrial & iot work and Next Devtools MCP for developer tools.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Plctap has no declared pricing — check the project's own site. Next Devtools MCP is listed as free. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add plctap and vercel-next-devtools-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Plctap has a quality signal of 56/100 (Good) with 3 views, 0 installs and 2 GitHub stars. Next Devtools MCP has 86/100 (Excellent) with 9 views, 0 installs and 832 GitHub stars.