Skip to main content
Glama
ymxc152

plctap

by ymxc152
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Plc Read

plc_read
Read-onlyIdempotent

Read data from PLCs across Modbus, FINS, MELSEC, S7, EtherNet/IP, and OPC UA. Specify protocol, address, count, and datatype to get interpreted values.

Instructions

从 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 说明。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostYes
portYes
unitNo
countNo
addressYes
optionsNo
datatypeNo
protocolYes
byteorderNobig
timeout_msNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetYes目标设备标识, 同时是连接池 key 的组成部分 (D1)。
addressYes
elapsed_msYes
interpretedNo
raw_registersYes
request_frameYes
interpretationsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.6.1
    • addedInput schema / properties / address / anyOf
      Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  }
+]
    • removedInput schema / properties / address / type
      Removed value: -"integer"
    • changedOutput schema / description
      Previous value: -"plc_read 输出。raw_registers 为寄存器原始 16 位值; interpreted 为按\ndatatype/byteorder 解释后的值。request_frame 保留 hex 便于人工核对。"New value: +"plc_read 输出。raw_registers 为寄存器原始 16 位值; interpreted 为按\ndatatype/byteorder 解释后的值。request_frame 保留 hex 便于人工核对。\naddress: 整数地址 (modbus/fins/melsec/s7) 或 tag 名字符串 (enip)。"
    • addedOutput schema / properties / address / anyOf
      Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  }
+]
    • removedOutput schema / properties / address / type
      Removed value: -"integer"
  2. First observedv0.4.0

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, and the description adds protocol-specific behavior such as S7 count being byte-based, OPC UA returning native values, and datatype None returning multiple interpretations. This meaningfully supplements the annotation safety profile without contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-organized, with protocol-specific semantics in a scannable bullet-like layout. Every sentence carries useful operational information, and the most critical parameter behavior is front-loaded before lower-level detail. No word is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity—10 parameters, 6 protocols, protocol-dependent semantics—and the absence of schema descriptions, the description is remarkably complete for tool selection and correct invocation. It covers protocol semantics, datatype behavior, byteorder effects, and options, while an output schema exists to cover return-value structure. Nothing essential for calling this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries full responsibility for parameters. It provides detailed semantics for address/count across six protocols, explains datatype choices including the None fallback, clarifies byteorder's effect on float32 pairs, and points to list_protocols for options. This thoroughly compensates for the lack of schema-level descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

State a specific verb and resource: read data areas from a PLC and interpret values by datatype. The protocol-specific address/count semantics make its scope concrete and distinguish it from sibling tools like plc_browse or probe_device. The title and name align cleanly with the described behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear operational guidance for when this tool is appropriate across different PLC protocols, and explicitly instructs agents to consult list_protocols for adapter-specific read_options. It does not explicitly name alternatives for non-read tasks, but the protocol coverage makes invocation conditions unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools