Skip to main content
Glama

get_node_info

Read-onlyIdempotent

Describe one ROS 2 node's topics, services, actions, parameters, and use_sim_time from the graph; report blocked parameter reads as findings, not errors.

Instructions

ROS 2 graph only; on a DDS-only setup use list_participants. Describe one ROS 2 node as a NodeInfo: the topics it publishes and subscribes to, the services and actions it serves or calls (each {name, type}), its parameters and use_sim_time. Interfaces come from the graph (ros2 node info), which never waits for the node. Parameters come from a read (ros2 param dump) bounded by timeout_s: a node that does not answer in time is a finding, not an error: parameters is null, parameters_note says its executor is probably blocked, and the interfaces are still returned. A value whose name contains password, secret, token, api_key or credential is replaced by <masked> and a long value is cut (truncated, original_size), both said in parameters_note. With several nodes of that name duplicate_count is above 1 and note warns. Raises an MCP error when the node is not on the graph (the message lists close matches), the name is malformed, or without a ros2 CLI. Read-only: the only request TopicForge ever sends is a parameter read (list/get); it sends no other request to a node. Duration: runs the ros2 CLI behind the ROS lock, one call at a time: up to three CLI calls (node list and node info, 8 s each at most; then the parameter read, at most timeout_s, 20 s). The whole call, lock wait included, ends within 45 s: if another ros2 call holds the lock it fails at once with a busy error (retry), and a call that waited has less time for the parameter read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeYesFully qualified node name as `list_nodes` gives it, e.g. `/robot1/lidar_driver` (a missing leading `/` is added).
timeout_sNoSeconds to wait for the parameter read, 1..20, default 8. A node that does not answer is reported in `parameters_note`, not as an error.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoOne sentence of context, or `None`.
full_nameYesFully qualified node name, e.g. `/lidar_driver`.
parametersNoParameters sorted by name; `None` when unreadable (see `parameters_note`); an empty list means none.
publishersYesTopics the node publishes.
subscribersYesTopics the node subscribes to.
use_sim_timeNoValue of the node's `use_sim_time` parameter. `None` when unknown: see `use_sim_time_note`.
action_clientsYesActions the node calls.
action_serversYesActions the node serves.
mode_effectiveYes`live` or `mock` (fixtures).
duplicate_countYesNodes using this exact full name; above 1, the data above belongs to one of them.
parameters_noteNoWhy `parameters` is `None`, or what was masked or cut; `None` when complete.
service_clientsYesServices the node calls.
service_serversYesServices the node offers, its own parameter services included.
use_sim_time_noteNoWhy `use_sim_time` is `None`. `None` when it is set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, yet the description adds substantial behavior beyond them: secret masking by keyword with <masked>, truncation with original_size, timeout semantics, lock contention producing a `busy` error, and a hard 45 s ceiling with the lock-wait tradeoff. It also clarifies that the only request sent is a parameter list/get.

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?

Front-loads the critical scope restriction before any detail, and each sentence carries real information (masking, timeouts, error conditions, duration). It is dense and long for a single paragraph, which costs it a point, but there is little waste.

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?

Even though an output schema exists, the description explains the non-obvious return semantics callers must interpret: null parameters vs. error, parameters_note, duplicate_count/note for ambiguous names, and masking/truncation markers. Combined with the duration and error model, an agent has everything needed to call and interpret it correctly.

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

Parameters3/5

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

Schema coverage is 100% and both params are documented in the schema, so the baseline is 3. The description largely restates node-name format and the 1..20/default-8 timeout, though it does add the nuance that a call that waited on the lock has less time for the parameter read.

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?

States a precise verb+resource ('Describe one ROS 2 node') and enumerates exactly what is returned (pub/sub topics, services/actions, params, use_sim_time). It also names the sibling list_participants as the alternative for DDS-only setups, so an agent can distinguish it from siblings without opening a schema.

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?

Explicit routing rule ('ROS 2 graph only; on a DDS-only setup use list_participants') plus clear when-not conditions: raises an MCP error for off-graph nodes, malformed names, or missing ros2 CLI, and a non-answering node is a finding to be reported rather than retried as an error.

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