Skip to main content
Glama

browse_opcua_nodes

Read-onlyIdempotent

Explore the OPC UA address space: list a node's children, walk a subtree, resolve a browse path by name to a node ID, or find nodes by name, class, and type definition.

Instructions

Explore the OPC UA address space: list a node's children, walk a subtree, resolve a human-readable browse path to a node ID, or search for nodes by name. With the defaults it lists the immediate children of node_id. Raise depth to walk further down, set node_class to 'Variable' to find only readable tags, and include_values to read each one as it is found. browse_path addresses a node by name instead of by ID ('/Objects/Reactor/Temperature'), which is how to start when you do not know the numeric IDs; with depth 0 it simply resolves that path and returns the node it names. name_filter keeps only nodes whose browse name contains the text. Every node also reports its type_definition — what it is, as against what class it belongs to: 'AnalogItemType' for a tag that publishes a unit and a range, a subtype of 'AlarmConditionType' for something act_on_alarm applies to, 'FolderType' for structure. Every traversal is bounded by max_nodes and says in truncated whether it stopped early, so a short list is never mistaken for a complete one.

Input Schema

NameRequiredDescriptionDefault
depthNoHow many levels below the starting node to walk. 1 (the default) lists its immediate children; 0 returns only the starting node itself, which is how to resolve a `browse_path` to a node ID. Clamped to 64.
node_idNoWhere to start, as a node ID. Defaults to the Objects folder 'ns=0;i=85', the root of the plant's own address space. Ignored when `browse_path` is given.
max_nodesNoStop after inspecting this many nodes (default 500, clamped to 5000). A traversal that stops early sets 'truncated' in the result.
node_classNoKeep only nodes of this OPC UA NodeClass: 'Variable' for readable tags, 'Object' for structure, 'Method' for callable operations. Every class is returned when unset. Filtering does not prune the walk — an Object is still descended into when `depth` allows.
browse_pathNoWhere to start, as a slash-separated browse path resolved through the server ('/Objects/Reactor/Temperature', or 'Reactor/Temperature' relative to `node_id`). Use this when you know what a thing is called but not its node ID. A path the server cannot resolve is an error, not an empty result.
name_filterNoKeep only nodes whose browse name contains this text, case-insensitively. Searching for 'temp' below the Objects folder is how to find a tag whose exact name you do not know.
include_valuesNoRead each Variable's current value as it is found (default false). Costs one extra read per variable, so leave it off when mapping a large address space and read what you need with read_opcua_nodes afterwards.

Output Schema

NameRequiredDescriptionDefault
resultYes
completenessYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds context beyond them: traversals are bounded by max_nodes, truncation is reported via 'truncated' so a short list isn't mistaken for complete, include_values costs one extra read per variable, node_class filtering does not prune the walk, and an unresolvable browse_path is an error rather than an empty result. These are exactly the non-obvious behaviors an agent needs.

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

Conciseness4/5

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

It is front-loaded with the four modes before drilling into each parameter, and every sentence carries operational information. It is on the long side as a single undivided paragraph, which slightly hurts scannability, but there is no filler.

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?

A 7-parameter traversal tool with an output schema is well covered: the description supplies the semantics the schema can't (type_definition, truncation, filter-vs-prune, path resolution errors) and doesn't waste space re-documenting return shapes the output schema already defines. Nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description earns a bump by adding semantics the schema does not: the depth-0 path-resolution idiom, the fact that node_class filtering is applied post-walk rather than pruning, and the explanation that type_definition describes what a node *is* versus its NodeClass. Minor gap: max_nodes' interaction with depth beyond the truncation note is only lightly treated.

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?

The description opens with a specific verb+resource ('Explore the OPC UA address space') and then enumerates the four concrete modes: list children, walk a subtree, resolve a browse path, search by name. It is clearly distinguishable from read_opcua_nodes (referenced explicitly as the way to fetch values afterwards) and from act_on_alarm (mentioned via 'AlarmConditionType').

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

Usage Guidelines5/5

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

It states the default behavior ('with the defaults it lists the immediate children of node_id') and then gives conditional routing: use browse_path when you don't know numeric IDs, set depth 0 to resolve a path, use name_filter for unknown names, and leave include_values off when mapping a large address space, reading with read_opcua_nodes instead. That is explicit when-to-use, when-not-to-use, and named alternatives.

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