Loading ToolBench
Bridge to LADS OPC UA laboratory devices. Call lads_connect(alias, server_url) first; then reference the alias in the other tools. Device / unit / function indices come from lads_list_devices and lads_get_functional_units.
Server has 7 tools with complete input schemas and descriptions. Naming follows verb_noun pattern (lads_connect, lads_list_devices, lads_get_*). Descriptions are present and contextual (avg ~120 chars), exceeding the 10-char minimum but below the 50-200 char LLM-optimized range. All parameters have type definitions and descriptions. However, output schemas are not formally documented, responses are inferred from code (dict returns). Error handling returns structured dicts with error fields but lacks recovery guidance (e.g., 'try X next'). No tool annotations (readOnlyHint/destructiveHint). Composition is sound: tools chain via alias + indices. Security concern: lads_register_alias stores plaintext passwords in YAML (acknowledged in description but not mitigated).
Open a connection to a LADS OPC UA server and store it under an alias. Idempotent per alias: re-connecting under an existing alias replaces the previous connection.
Connect using a persisted YAML alias. Convenience over lads_connect: no need to repeat the server_url. Fails if the alias is not in the YAML registry.
Return the functional units for a device, with per-unit function counts. Use device_index from lads_list_devices.
Read a sensor_value from a specific Function on a FunctionalUnit. Only meaningful for sensor-typed functions; returns an error dict for functions without a sensor_value attribute (e.g. control functions).
List persisted YAML aliases (~/.rei-lads/aliases.yaml). Each alias resolves to a LADS server_url and can be used with lads_connect_by_alias.
List LADS devices exposed by the server registered under alias.
Output schemas not formally documented. Responses are inferred from code (dict returns with 'error', 'alias', 'count', 'devices', etc.). LLMs cannot reliably parse undocumented output structures, risking field extraction errors and downstream tool call failures.
Error responses lack recovery guidance. When alias is unknown or index out of range, errors return the problem but not the next step (e.g., 'Call lads_list_aliases() to see available aliases'). This forces LLMs to guess recovery actions.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). lads_connect and lads_register_alias are destructive (replace connections/aliases) but lack destructiveHint. lads_list_* are read-only but lack readOnlyHint. Agents cannot distinguish safe from risky tools without explicit hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Persist a YAML alias -> server_url mapping. Overwrites existing alias. Auth (user/password) is optional; password is stored as plaintext in the YAML file — do not use for production without OS-level file permissions.
Plaintext password storage in YAML. lads_register_alias stores credentials in ~/.rei-lads/aliases.yaml without encryption. Description acknowledges this ('do not use for production without OS-level file permissions') but does not mitigate. Violates secret-injection pattern.
Descriptions lack WHEN-to-use guidance. E.g., lads_get_sensor_value says 'Read a sensor_value' but does not explain when to call it vs other tools or what 'sensor-typed functions' means. LLMs cannot infer selection criteria from names alone.