TopicForge

Overview Schema Source Related Servers Discussions Admin

get_node_info

Read-onlyIdempotent

Inspect a ROS 2 node to list its topics, services, actions, and parameters, and flag blocked executors or masked secrets in its parameter dump.

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 params_file, param_diff lists declared values that differ on the node, are declared_only or masked. 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: ros2 CLI behind the ROS lock, one call at a time; up to three CLI calls (node list and info, 8 s each at most; the parameter read, at most timeout_s, 20 s); ends within 45 s, less time for the read after a wait; busy error if the lock is held (retry).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "node": "<node>"
    },
    "name": "get_node_info"
  }
}

Input Schema

Name	Required	Description
`node`	Yes	Fully qualified node name as `list_nodes` gives it, e.g. `/robot1/lidar_driver` (a missing leading `/` is added).
`timeout_s`	No	Seconds 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.
`params_file`	No	Server path of a ROS 2 parameter `.yaml` (1 MiB max).

Output Schema

Name	Required	Description
`note`	No	One sentence of context, or `None`.
`full_name`	Yes	Fully qualified node name, e.g. `/lidar_driver`.
`lifecycle`	No	True when `service_servers` has `<full_name>/get_state` (GetState).
`param_diff`	No	File against node: differences only.
`parameters`	No	Parameters sorted by name; `None` when unreadable (see `parameters_note`); an empty list means none.
`publishers`	Yes	Topics the node publishes.
`subscribers`	Yes	Topics the node subscribes to.
`use_sim_time`	No	Value of the node's `use_sim_time` parameter. `None` when unknown: see `use_sim_time_note`.
`action_clients`	Yes	Actions the node calls.
`action_servers`	Yes	Actions the node serves.
`mode_effective`	Yes	`live` or `mock` (fixtures).
`duplicate_count`	Yes	Nodes using this exact full name; above 1, the data above belongs to one of them.
`param_diff_note`	No
`parameters_note`	No	Why `parameters` is `None`, or what was masked or cut; `None` when complete.
`service_clients`	Yes	Services the node calls.
`service_servers`	Yes	Services the node offers, its own parameter services included.
`use_sim_time_note`	No	Why `use_sim_time` is `None`. `None` when it is set.
`param_diff_summary`	No	Left out of `param_diff`: same, live_only, with names.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.1Oct 27, 2026

changedOutput schema / properties / param_diff_summary / description

Previous value: -"Counts left out: same, live_only."New value: +"Left out of `param_diff`: same, live_only, with names."

Changed25 schema fields changedv0.8.0Oct 21, 2026

addedInput schema / properties / params_file

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Server path of a ROS 2 parameter `.yaml` (1 MiB max)."
+}

removedOutput schema / $defs / NodeParameter / properties / original_size / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

removedOutput schema / $defs / NodeParameter / properties / original_size / default
```
Removed value: -null
```
addedOutput schema / $defs / NodeParameter / properties / original_size / type
```
Added value: +[
+  "integer",
+  "null"
+]
```

addedOutput schema / $defs / ParamDiff

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "declared": {
+      "$ref": "#/$defs/JsonValue"
+    },
+    "live": {
+      "$ref": "#/$defs/JsonValue"
+    },
+    "name": {
+      "type": "string"
+    },
+    "status": {
+      "description": "`declared_only`: absent on the node.",
+      "enum": [
+        "different",
+        "declared_only",
+        "masked"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "status",
+    "declared",
+    "live"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / lifecycle

Added value: +{
+  "description": "True when `service_servers` has `<full_name>/get_state` (GetState).",
+  "type": "boolean"
+}

removedOutput schema / properties / note / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedOutput schema / properties / note / default
```
Removed value: -null
```
addedOutput schema / properties / note / type
```
Added value: +[
+  "string",
+  "null"
+]
```

addedOutput schema / properties / param_diff

Added value: +{
+  "description": "File against node: differences only.",
+  "items": {
+    "$ref": "#/$defs/ParamDiff"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

addedOutput schema / properties / param_diff_note

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / param_diff_summary

Added value: +{
+  "description": "Counts left out: same, live_only.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

removedOutput schema / properties / parameters / anyOf

Removed value: -[
-  {
-    "items": {
-      "$ref": "#/$defs/NodeParameter"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

removedOutput schema / properties / parameters / default
```
Removed value: -null
```

addedOutput schema / properties / parameters / items

Added value: +{
+  "$ref": "#/$defs/NodeParameter"
+}

addedOutput schema / properties / parameters / type
```
Added value: +[
+  "array",
+  "null"
+]
```

removedOutput schema / properties / parameters_note / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedOutput schema / properties / parameters_note / default
```
Removed value: -null
```
addedOutput schema / properties / parameters_note / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / use_sim_time / anyOf

Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]

removedOutput schema / properties / use_sim_time / default
```
Removed value: -null
```
addedOutput schema / properties / use_sim_time / type
```
Added value: +[
+  "boolean",
+  "null"
+]
```

removedOutput schema / properties / use_sim_time_note / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedOutput schema / properties / use_sim_time_note / default
```
Removed value: -null
```
addedOutput schema / properties / use_sim_time_note / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Addedv0.7.1Oct 14, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the annotations: it discloses masking rules for secret-looking names, truncation with `original_size`, that a timed-out parameter read is a finding rather than an error (`parameters: null` + `parameters_note`), the MCP-error conditions (node absent, malformed name, no CLI), and the lock/serialization behavior with a `busy` retry hint. The duration budget (up to three CLI calls, 45 s ceiling, 20 s max read) is quantified rather than hand-waved.

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-loaded with the applicability constraint and the alternative, then the return shape, then failure modes and timing — a sensible order with dense, fact-bearing sentences. The read-only sentence is slightly redundant ("the only request ... it sends no other request to a node") and the block is long, but nearly every clause carries a distinct fact.

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?

For a three-parameter read tool with an output schema, the description covers everything the agent needs: when it applies, what the response fields mean, how failure is represented (error vs. finding), masking/truncation side effects, and the full duration/lock budget. Nothing material is left to inference.

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 already 100%, so the description's added value is what matters: it explains that `timeout_s` bounds only the parameter read and that expiry surfaces in `parameters_note`, and that `params_file` produces a `param_diff` with `declared_only` and `masked` markers — meaning the schema's bare "Server path of a ROS 2 parameter .yaml" does not convey. It stops short of explaining value-format expectations for the yaml.

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 specific verb and resource ("Describe one ROS 2 node as a `NodeInfo`") and enumerates exactly what is returned: topics, services, actions, parameters and `use_sim_time`. It also scopes itself ("ROS 2 graph only") against the `list_participants` sibling, so the agent can distinguish it 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 Guidelines4/5

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

Gives an explicit exclusion plus the named alternative: on a DDS-only setup, use `list_participants` instead. It also states the underlying mechanism (`ros2 node info`, `ros2 param dump`) so the agent knows what preconditions apply, but it does not say when to prefer `list_nodes` first or when to reach for `get_topic_info` instead.

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

Deploy Server