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

With no annotations, the description carries the full burden, and it does well: it discloses that output varies by mode, that show_types affects the listing, that details are 'returned raw' (原文返回), and that failures return an error. The only gap is it doesn't describe the return format or size beyond that.

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

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

Tight and front-loaded: purpose, when-to-use, the two behaviors, the parameter note, and error handling in a few lines with zero filler.

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

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

For a read-only introspection tool with two params, no annotations, and no output schema, the description tells the agent enough to call it correctly in both modes. Slightly more on the detail-mode return contents would make it fully complete.

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

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

Schema coverage is 0%, so the description must compensate, and it covers both parameters: show_types (attaches type info when True) and action_name (full name, leading slash, example /rotate_absolute). The example is the main value-add, though no constraints beyond the format are elaborated.

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

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

States a specific verb+resource: query ROS2 actions, and names the two distinct modes (list all vs. inspect one). An agent can easily separate this from siblings like list_nodes, list_topics, and params, which cover different ROS2 entities.

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

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

The 何时用 line explicitly scopes usage to two situations (seeing which actions exist, and who provides one). It gives clear context but names no alternative tool or exclusion condition, so it stops short of 5.

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

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

With no annotations, the description carries the full burden and mostly succeeds: it discloses the return shape (raw CLI sectioned report with named sections) and failure semantics (error return, likely causes: typo'd name, node just exited). It does not discuss permissions or read-only nature, but for an inspection tool the disclosure is solid beyond structured fields.

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

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

Three labeled blocks (purpose / when-to-use / params+returns) with the function statement front-loaded and zero filler; every sentence carries information an agent needs.

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

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

No output schema and no annotations exist, so the description must supply both the return format and failure behavior it does. For a single-parameter, read-only introspection tool, nothing needed 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.

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

Schema description coverage is 0%, so the description must compensate and does: it specifies the expected format (fully-qualified name, leading '/', e.g. /talker) and the case-sensitivity constraint, which is precisely the syntax the bare string schema lacks.

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

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

States a specific verb+resource ('get connection details for a node') and enumerates the exact facets returned (topics, services, actions), which cleanly separates it from siblings like get_topic_info, show_interface, and list_nodes. An agent can identify the right tool 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.

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

Explicit '何时用' section names the triggering condition (known node name, want to see its connections) and a concrete drill-down workflow with the sibling system_overview. No alternative is left implicit for the node-introspection case.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the return format ('raw CLI output') and the failure behavior (returns error, commonly when the topic does not exist). It is implicitly a read operation, though permission scope and any performance cost of verbose enumeration are not stated.

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

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

Well front-loaded: purpose first, then when-to-use, then parameter notes, then return/error behavior. The labeled sections make it scannable and every sentence adds information an agent needs; no filler.

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

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

For a 2-parameter, no-output-schema, no-annotation tool, the definition covers purpose, invocation triggers, parameter formatting, return shape, and the common error case. Nothing required 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.

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

Schema description coverage is 0%, so the description must compensate and it does: topic is specified as the full name beginning with '/' (e.g., /chatter) and explicitly case-sensitive, and verbose is explained as attaching per-endpoint QoS detail with a recommendation to enable it. Both parameters gain semantics not present anywhere in the schema.

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

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

The description opens with a specific verb+resource and enumerates exactly what is retrieved: message type, publisher count, subscriber count, and QoS. This is clearly distinguishable from siblings like list_topics (enumeration), sample_topic (data sampling), and get_topic_rate (rate measurement). An agent can select it without opening the schema.

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

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

The '何时用' section gives concrete when-to-use triggers: confirming a topic's datatype and diagnosing 'published but nobody receives it' scenarios via the publisher/subscriber counts and QoS. It does not name alternatives (e.g., list_topics or sample_topic) or state when not to use it, but the usage context is clear and actionable.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: the observation window, the None fallback for average_rate_hz when nothing was measured, the raw_tail output, and a note field explaining why a rate was missed. It omits whether it registers a subscriber/load on the system or any permission requirements.

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

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

Compact and labeled: purpose, when-to-use, parameters, return values, and failure note. Every sentence adds information and the purpose is front-loaded.

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

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

For a simple two-parameter observation tool with no annotations and no output schema, the description covers inputs, the return fields, and the failure mode, leaving nothing an agent needs in order to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate and it does: topic is documented as the full name starting with '/', and duration_s is bounded to 1~15 seconds with a stated default of 5. Both parameters gain meaning that the bare schema lacks.

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

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

States a specific verb+resource: observe a topic for duration_s seconds and return its average publish frequency. It is clearly distinct from siblings like list_topics, get_topic_info, or sample_topic, which enumerate or inspect rather than measure rate over a window.

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

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

The '何时用' line gives an explicit diagnostic scenario: troubleshooting 'data not updating / updating too slowly'. It provides clear context for invocation but names no sibling alternatives or explicit when-not-to-use conditions.

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

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

With no annotations, the description carries the full burden and does well: it discloses the latency ceiling (~30s because doctor runs network checks) and the failure behavior (an error field is returned). What it doesn't cover (permissions, whether the check is purely read-only) is minor for a diagnostic tool, so a 4 is warranted.

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

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

The description is sectioned into purpose, when-to-use, return values, and cautions, with the most decision-relevant content (purpose and trigger) front-loaded. Every sentence earns its place; the return-field list is terse and non-redundant.

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

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

There is no output schema, so the description fully documents the return shape: daemon_running, doctor_returncode with its enumerated values (0/1/2), verdict, warnings_found, raw_tail, plus the error field on failure. Nothing an agent needs to interpret the result is missing.

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

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

The tool takes zero parameters, so parameter semantics require no explanation and the baseline of 4 applies. There is no input whose meaning could be ambiguous.

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

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

Names a specific action (health check) and a specific resource (the ROS2 environment itself), explicitly distinguishing it from business-node tools. The scope is bounded to daemon status plus doctor diagnosis, so an agent immediately knows what class of problem this tool addresses.

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

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

Explicitly states when to use it: when the problem is suspected to lie in the ROS environment/network/daemon rather than business nodes, or when list_nodes comes back empty and further localization is needed. It names the sibling list_nodes and the exact triggering condition, leaving nothing to inference.

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

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

With no annotations, the description carries the behavioral burden and does well: it states the return fields node_count and nodes, explains that empty nodes means no nodes were discovered, lists likely causes, and notes the error field on failure. It does not explicitly state that the operation is read-only or discuss performance/rate characteristics, but for a zero-parameter listing tool this is minor.

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

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

Front-loads the purpose, then follows with when-to-use, return shape, empty-result interpretation, and failure behavior. Every sentence adds useful operational context without wasted words.

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

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

There is no output schema, so the description must explain return values, which it does by naming node_count and nodes and describing their format. It also covers the empty and error cases, making the definition complete for this simple inspection tool.

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

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

The tool takes no parameters, so the baseline is 4. The description correctly does not invent parameter documentation, and the empty schema needs no further semantic explanation.

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

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

Stated as a specific verb and resource: lists all currently running ROS2 node names. The scope (current ROS2 system, all running nodes) clearly separates it from get_node_info, list_topics, and other siblings.

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

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

Explicitly says when to use it: to confirm whether a node is alive and to survey the system before troubleshooting. It also names health_check as the follow-up when no nodes are found, though it does not compare against all sibling diagnostics tools.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully states the return shape (topic_count, topics list with name and type, and an error field on failure), but omits safety profile, authentication needs, rate limits, or pagination behavior. Moderate transparency for a read-like operation.

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

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

Three short sentences, front-loaded with purpose, then usage, then return values. No redundancy, filler, or tangential detail. Every sentence earns its place.

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

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

This is a low-complexity tool with an empty input schema and no output schema. The description compensates by specifying the return shape (topic_count plus topics with name and type fields, and an error field on failure), giving the agent enough to call and interpret results.

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

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

The tool takes zero parameters, so the schema provides no parameter semantics to supplement. Per the rules, a zero-parameter tool earns a baseline of 4, and the description appropriately adds no unnecessary parameter detail.

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

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

States a specific verb '列出' (list) and resource '全部话题' (all topics) plus message types, making the action clear. It does not explicitly differentiate from sibling get_topic_info, but the '全部' scope implies bulk listing versus single-topic detail.

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

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

Provides explicit when-to-use guidance: '想看系统里在传什么数据、某个话题的类型是什么。' This gives clear context for selection. However, it does not name alternatives (e.g., get_topic_info for one topic) or state when not to use the tool.

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

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

With no annotations, the description carries the burden and does add real behavioral context: it runs without ROS installed, is pure Python with zero subprocesses, and produces a verdict plus hints. It does not explicitly state that it is read-only or disclose runtime cost, but the self-contained/no-subprocess note is genuinely useful for an agent deciding whether it is safe to call.

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

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

Front-loads the purpose, then uses labeled 'when to use' and 'returns' blocks. The return enumeration is somewhat long but each item is informative rather than filler, so the structure earns its length.

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

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

With no output schema available, the description compensates by enumerating the returned fields (OS/kernel/arch, CPU/mem/disk, network, hostname resolution, locale, ROS_DOMAIN_ID) and calling out the verdict and hints outputs. An agent knows both what the tool does and what it will get back.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter surface for the description to clarify.

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

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

States a specific verb+resource: evaluating whether the local machine can install/run ROS2, with the added scoping detail that it is a pre-install health check. It implicitly separates itself from siblings like system_overview and health_check via the ROS support-matrix comparison, but never names those siblings directly.

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

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

Gives an explicit usage context ('体检 before installing ROS / deploying robot software'), which tells the agent when to reach for this tool. It stops short of naming alternatives or stating when NOT to use it, so it is clear context without exclusions.

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

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

With no annotations, the description carries the full burden and does well: it declares the read-only/no-set constraint, explains the 'raw' field's type-prefixed format ('Integer value: 10'), and documents the failure mode (returns error for misspelled node or unknown parameter). It does not cover permissions or behavior for complex/nested parameter values.

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

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

Front-loaded purpose, then usage, then parameter rules, then return/failure behavior. Every line adds information with no padding.

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

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

With no annotations and no output schema, the description still covers the essentials an agent needs: semantics of the optional parameter, the shape of the returned value, and the failure contract. Nothing material is missing for a two-parameter read tool.

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

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

Schema coverage is 0%, so the description must compensate, and it does: 'node' is a full name with a leading slash, 'name' has no leading slash and may contain '.' and '/', and the omitted-vs-provided distinction (list all names vs read one value) is spelled out explicitly.

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

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

States a specific verb and resource: reads the parameters of a given ROS node, explicitly read-only ('只读，不支持设置'). An agent can tell this apart from generic node inspection tools, though no sibling is named to sharpen the boundary against get_node_info/list_nodes.

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

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

Gives an explicit 'when to use' clause: inspecting a node's configuration or the current value of a behavior switch. It does not name alternatives or state when-not-to-use, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does well: it names what is returned (installed flag, distro list with paths, PATH availability, the distro the MCP tools will use, ROS env vars) and clarifies it works without ROS installed. It stops short of an explicit read-only/no-side-effect statement, which would complete the safety profile.

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

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

Front-loaded with the purpose, then clearly labeled '何时用' and '返回' sections. It is slightly verbose but every line carries meaning; no filler or repetition.

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

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

No output schema exists, and the description compensates by enumerating the return fields and the preflight ordering role. For a zero-parameter detection tool with no annotations, 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.

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

Zero parameters, which warrants the baseline 4; there are no inputs to disambiguate, and the description correctly spends no words on parameters.

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

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

States a specific verb+resource: detect whether ROS2 is installed and which distros are present, plus that it runs without ROS installed. An agent can distinguish this preflight probe from the sibling inspection tools (list_nodes, list_topics, etc.) without opening any schema.

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

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

The '何时用' block gives an explicit triggering condition (uncertain whether ROS exists, which version, whether tools can run) and an explicit ordering rule — call this first, then decide which inspection tools to use. So it directly routes the agent relative to siblings.

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

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

With no annotations, the description carries the full burden and does well: it guarantees the command always returns within the limit and '不会挂起' (never hangs), enumerates stopped_because outcomes (message_limit / timeout / publisher_stopped), and notes the no-message case via a note field. It omits auth/permission needs or rate limits, keeping it below 5.

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

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

Front-loads the core action in the first sentence, then separates 何时用 / 参数 / 返回 into scannable sections. Reasonably economical, though slightly verbose in restating defaults already present in the schema.

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

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

There is no output schema, yet the description documents the return shape (messages_received, stopped_because, raw unparsed payload, and the note field when empty), so an agent can interpret results correctly. Combined with full parameter documentation, nothing essential is missing.

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

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

Schema coverage is 0%, so the description must compensate, and it does: topic is specified as a fully-qualified name beginning with '/', max_messages as 1–50 with default 5, timeout_s as 1–15 with default 5. All three parameters get concrete ranges and semantics absent from the schema.

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

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

States a specific verb+resource ('限时采样话题内容' – sample topic content with a time bound) and an explicit scope (max_messages cap or timeout). This is clearly distinguishable from siblings like get_topic_info or get_topic_rate, which describe metadata rather than actual sampled payloads.

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

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

Explicitly gives the when-to-use context: 'when you want to see what the data in a topic actually looks like and whether field values are reasonable.' It does not name an alternative tool or state when NOT to use it, so it falls short of the 5-level routing guidance.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose the return shape (definition field with raw field text) and failure behavior (error on typo or missing package). It does not explicitly state that the call is read-only/has no side effects, so a small gap remains.

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

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

Front-loaded purpose followed by clearly labeled when-to-use, parameter, and return sections; every sentence earns its place with no filler.

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

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

For a single-parameter read tool with no output schema or annotations, the description covers purpose, invocation trigger, parameter format, return field, and error cases — everything an agent needs to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it specifies the 包/类型/名称 format and gives three concrete examples spanning msg, srv, and action variants. This adds meaning the bare string schema entirely lacks.

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

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

Names a specific verb (查看/view) and resource (ROS2 消息/服务/动作类型的字段定义), making clear this is about interface type definitions rather than topics, nodes, or params like the siblings. An agent can distinguish it from sample_topic or get_topic_info without opening any schema.

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

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

Explicit '何时用' section states the exact trigger condition — having a type name such as the 'type' returned by sample_topic — which directly links it to a sibling tool. This is precise when-to-use guidance rather than implied usage.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does disclose meaningful traits: the 12-node expansion cap with a notes field caveat, and failure semantics (returns error/notes without interrupting the session). It stops short of describing read-only guarantees or performance/cost characteristics, but the operational behaviors that matter for invocation are covered.

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

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

Front-loaded with the purpose, then clearly sectioned into usage and returns, with no filler. The return section enumerates several field names, which is slightly verbose, but each line earns its place by clarifying scope or output shape.

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

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

With no output schema and no annotations, the description supplies exactly what is missing: the return payload structure (node_count/topic_count, nodes, topics with types, connections), the truncation rule, and failure handling. An agent has everything needed to call it and interpret the result.

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

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

The tool takes zero parameters and schema coverage is complete, so there is nothing for the description to document. Baseline 4 applies; the description correctly adds no parameter noise.

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

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

States a specific verb and resource: a one-page snapshot of the current ROS2 system covering nodes, topics, connections and counts. It also implicitly scopes itself against the drill-down siblings, so an agent can distinguish it from list_nodes/get_node_info 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.

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

Explicitly designates itself as the first entry point for "what is the system state now" questions, and names the follow-up alternatives (get_node_info / get_topic_info / sample_topic) with the condition that triggers them (an anomalous node/topic is found). When-to-use and when-to-escalate are both stated.

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