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

No annotations are provided, so the description carries the full burden. It only restates the core action and does not disclose cancellation semantics, possible failure modes, whether cancellation is synchronous, or what happens if the goal is no longer executing.

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 compact and front-loaded with the main purpose, followed by a brief Args block. It is easy to scan, though the parameter lines offer minimal additional value.

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 cancellation tool, the core purpose and inputs are present. However, with no annotations and no usage guidance, an agent is missing context about cancellation behavior and how the goal identifier relates to a previously sent action goal.

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. It provides only 'Name of the action' and 'Identifier of the goal to cancel,' which add little beyond the schema's titles and do not explain how to obtain a goal_id or what format is expected.

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 starts with 'Cancel an executing ROS2 action goal,' which clearly states the operation (cancel) and the resource (action goal). It is easily distinguished from siblings like ros2_action_send_goal, so an agent can tell what this tool is for.

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 word 'executing' implies this tool is for active goals, but there is no explicit guidance on when to use it versus alternatives, nor any mention of when not to use it. The intended context is inferable but not stated.

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 behavioral burden. It explicitly discloses blocking behavior via wait_for_result, timeout semantics via timeout_sec, and the optional wait-for-result design. It does not describe error behavior or what happens to a running goal when not waiting, but the core blocking and timing traits are transparent.

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 front-loaded with a one-sentence purpose followed by a compact Args list. Every line adds useful meaning, with no filler or redundant restatement of the tool name.

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?

Given the existence of an output schema, return-value details are not required here. The description covers all parameter semantics and the send/wait behavior needed to make a basic call. The main gap is not addressing what the agent should do when wait_for_result is false or when the action should be canceled instead.

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%, but the description compensates by explaining every parameter. It gives concrete examples for action_name and action_type, clarifies goal_data as a JSON dict, and defines the semantics of wait_for_result and timeout_sec well beyond their generic schema titles.

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 'Send a goal to a ROS2 Action server and optionally wait for result,' which uses a specific verb and resource. This clearly distinguishes the tool from sibling actions like ros2_action_cancel_goal or topic publishing tools.

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 intended use is implied through the action-send terminology and the parameter explanations, but the description does not explicitly state when to prefer this over ros2_action_cancel_goal or other ROS2 interaction tools. There is no when-to-use / when-not-to-use 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?

With no annotations provided, the description carries the full behavioral burden. It does disclose useful traits: timeout_sec is a max wait duration, and condition_expr is a Python expression evaluating 'msg', indicating how matching works. However, it does not state what happens on failure—whether it raises an error, returns false, or times out silently—leaving an important behavioral gap.

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 a compact docstring: a one-sentence summary followed by a structured Args block. Each line serves a purpose, with examples embedded in parameter explanations. There is no fluff, repetition, or tangential information.

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?

All four parameters are well documented, and the core behavior is clear from the summary. Since an output schema exists, return values need not be detailed in the description. The only minor gap is the unspecified failure behavior, but the 'assert' verb and timeout semantics make the tool's contract mostly 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 description coverage is 0%, so the description fully compensates. Every parameter is explained with concrete examples: topic gives '/robot/cmd_vel', topic_type gives 'geometry_msgs/msg/Twist', condition_expr gives a Python expression pattern, and timeout_sec is defined as max wait duration in seconds. This meaning goes well beyond the bare 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 clearly states the tool's function: 'Assert that a message matching an optional condition has been published to a topic.' The verb 'assert' plus the topic resource is specific and distinct from sibling tools like publishing or echoing. The optional condition is immediately mentioned, further narrowing the purpose.

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 description implies usage through its name and purpose—use it to verify a message was published—but it provides no explicit guidance on when to choose this tool over siblings like ros2_topic_echo (for continuous observation) or ros2_measure_topic_hz (for rate measurement). No alternatives or exclusions are mentioned.

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 provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool makes a service call and returns a response, and it discloses the timeout behavior via the 'timeout_sec' parameter. This covers the core behavioral traits. It does not mention side effects or error handling, but for a service call that is typical.

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 a compact docstring with a one-line purpose followed by a parameter list. It is front-loaded with the action and uses standard Args formatting. Every sentence is informative, with no redundant or filler content.

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?

The description covers all input parameters needed to call the tool correctly. Since an output schema exists, return value details are not required. The description could optionally mention that service types are discoverable via ros2_get_services, but this is not essential. The tool is sufficiently described for an agent to invoke it.

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. It does so by explaining each parameter: service name with examples, service_type with an example, request_data as a JSON object/dict, and timeout_sec as maximum wait time. This adds significant meaning beyond the raw schema fields.

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 states a clear verb-resource pair: 'Call a ROS2 service and receive the response.' It is specific about the action and distinguishes this tool from topic/action tools (siblings include ros2_topic_publish, ros2_action_send_goal). The intent is unambiguous and matches the tool name.

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 description implies usage whenever a service needs to be invoked, and it provides clear context (service name, type, request data, timeout). It does not explicitly mention alternatives or when NOT to use it, but the context is sufficient for an agent to decide. No exclusions are stated, so it scores a 4.

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 provided, the description carries the full behavioral burden. 'List' clearly signals a read-only operation, and 'active' indicates it reflects the current runtime graph. The description is transparent about what is included (namespace, pub/sub topics, services) without hidden side effects.

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?

A single, front-loaded sentence communicates the action, the resource, and the returned data with zero redundancy. Every word 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?

For a zero-parameter, read-only listing tool, the description is nearly complete. It names the returned fields, and the output schema exists to cover the exact structure. Lacking only explicit guidance on when to choose a sibling tool, which is already accounted for in usage_guidelines.

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?

This tool has zero parameters, and the schema is trivially fully covered. The description adds meaningful context by specifying the resource scope ('all active ROS2 nodes') and the returned fields, which is more than the empty schema alone provides.

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 names a specific verb ('List'), a clear resource ('active ROS2 nodes'), and details the returned content ('namespace, pub/sub topics, and services'). This distinguishes it from sibling tools like ros2_get_topics and ros2_get_services while remaining immediately understandable.

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 description implies when to use the tool: when an agent needs node-level introspection with associated topics and services. However, it does not explicitly say when to prefer sibling tools, such as using ros2_get_topics for topic-only queries or ros2_get_services for service-only queries.

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 provided, the description carries the full burden of behavioral disclosure. It states the operation is a read ('Get parameter values') but doesn't disclose what happens if the node doesn't exist, if a parameter name is invalid, or whether it returns all parameters when 'names' is empty. The description is minimal and doesn't add behavioral context beyond the basic read 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?

The description is concise and front-loaded with the core purpose. The Args section is a bit redundant with the schema but adds useful examples. No wasted words, though the format is more like a docstring than a tool description.

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?

The tool has an output schema (not shown in detail) and only 2 required parameters, both explained. However, for a read operation with no annotations, the description doesn't cover error cases, return value semantics, or how it differs from ros2_get_nodes (which might also expose parameters). It's adequate for a simple getter but lacks edge-case guidance.

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. It does explain both parameters: node_name is 'Full name of the node (e.g. '/robot/diff_drive_controller')' and names is 'List of parameter names to read'. This adds meaning beyond the raw schema (which only has titles 'Node Name' and 'Names'), but it doesn't provide details like parameter name format, wildcard support, or behavior with empty lists.

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 clearly states the tool's function: 'Get parameter values for a specific ROS2 node.' It identifies the resource (ROS2 node parameters) and the verb (get). It distinguishes itself from siblings like ros2_set_parameters (which writes) and ros2_get_nodes (which lists nodes), though it doesn't explicitly name them.

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 description implies usage context: it's for reading parameter values from a specific node, which is distinct from setting parameters (ros2_set_parameters) or listing nodes (ros2_get_nodes). However, it doesn't explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites like node availability or parameter existence.

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 itself must convey behavior. The verb 'List' signals a read-only operation, and 'active ... available in the graph' clarifies scope. It lacks detail about possible empty results or daemon dependencies, but for a no-argument introspection tool this is reasonable.

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?

A single, front-loaded sentence states exactly what the tool does with no filler or redundancy.

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 no-parameter, read-only listing tool with an output schema, the description is sufficient for an agent to invoke it correctly. It does not explain the relationship to ros2_call_service, but that is not essential for this tool's own invocation.

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 has zero parameters, so parameter semantics are trivially covered by the empty input schema. The baseline of 4 applies because there is nothing for the description to add.

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 uses a specific verb ('List') and resource ('all active ROS2 services available in the graph'). This clearly distinguishes it from sibling tools like ros2_get_nodes, ros2_get_topics, and ros2_call_service.

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?

No guidance is given about when to use this tool versus alternatives, such as ros2_call_service for invoking a service or ros2_health_check for graph status. The context of service discovery is implied but not stated.

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?

Annotations are absent, so the description carries the full burden of behavioral disclosure. 'List' strongly implies a read-only operation with no side effects, and the description does not claim any mutation. However, it does not explicitly state that it is non-destructive, does not mention whether a live ROS2 system is required, and does not describe what happens when no topics exist. This is adequate but leaves room for inference.

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 a single, well-structured sentence with no filler words. It states the action, the resource, and the additional information returned, all in one efficient line. Every part 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?

The tool is simple (no parameters), and an output schema exists, so the description need not explain return values. However, given the absence of annotations, a short note about read-only nature or the requirement of a running ROS2 environment would improve completeness. As-is, it covers the core functionality well but is not exhaustive for a completely annotation-free 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?

There are zero parameters, and the schema is empty, so the baseline for parameter semantics is 4. The description's phrase 'all available' adds meaning by indicating the tool returns a complete view of the topic graph, but because there are no parameters to elaborate on, the description does not need to compensate for any schema gaps. It appropriately represents the no-argument behavior.

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 uses a specific verb ('List') and a specific resource ('all available ROS2 topics'), and goes beyond the bare name by specifying the additional detail that publisher and subscriber nodes are included. This clearly differentiates it from sibling tools like ros2_get_nodes (lists nodes) and ros2_get_services (lists services), so an agent can select it without ambiguity.

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 description gives clear context: it is for listing topics, and the mention of 'available' implies that the ROS2 graph must be reachable. It does not explicitly state exclusions such as 'use ros2_topic_echo to inspect specific message content' or 'use ros2_get_services for services', but the purpose is unambiguous enough that an agent can infer when this tool is appropriate, especially given the sibling names.

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 behavioral burden. 'Check' reasonably signals a read-only diagnostic action, but the description does not explain what the check actually performs, how 'serving health' is determined, or what failure looks like. It is not misleading, but it is thin.

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?

A single, front-loaded sentence with no filler or repetition. The typo 'wrosbridge' is minor and does not obscure the meaning.

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 zero-parameter tool with an output schema, the description is mostly sufficient: it names both connection health and serving health. It could be clearer about what endpoint or gateway configuration is targeted, but invocation itself requires no additional information.

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 has zero parameters and the schema's 100% coverage fully documents that. A baseline of 4 is appropriate because there is nothing for the description to add about 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?

The description uses a specific verb ('Check') and identifies a concrete resource ('remote wrosbridge gateway'). Its health-check intent is clearly distinct from the sibling tools, which focus on publishing, echoing, inspecting, or manipulating 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?

There is no guidance about when to run this tool, what prerequisites exist, or how it relates to the sibling tools. An agent must infer that this is a preliminary diagnostics step, but nothing in the description states that explicitly.

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?

The description says 'Lookup' which implies a read-only operation, but it does not explicitly state that it does not modify anything. It also does not disclose behavior when frames are missing, the meaning of the timeout in practice (e.g., if it throws an error on timeout), or whether the lookup might block. Since no annotations are provided, the description carries the full burden of behavioral disclosure, and it fails to provide sufficient detail about side effects or error conditions.

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 extremely concise, with the primary action front-loaded in the first line, followed by a clean list of parameter definitions. There is no fluff or redundant information. It is easy to scan and understand quickly, which is ideal for an agent.

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?

The description covers the core purpose and all parameters, and an output schema exists, so return value details are not needed. It is largely complete for a simple lookup tool. However, it omits any mention of prerequisites (e.g., an active TF tree) or potential failure modes, but given the tool's simplicity and the presence of an output schema, the description is adequate for an agent to make a reasonable call.

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 description provides meaning for all three parameters, including concrete examples: target_frame: 'Target coordinate frame (e.g. 'odom' or 'map')', source_frame: 'Source coordinate frame (e.g. 'base_link' or 'camera_link')', and timeout_sec: 'Timeout in seconds'. This adds significant value over the input schema, which has zero description coverage. However, it does not clarify the direction of the transform (e.g., whether it returns the transform from source to target or target to source), which could lead to ambiguity.

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 clearly states the tool's function: 'Lookup geometric coordinate transform between two frames from ROS2 TF tree.' This is a specific verb+resource combination that distinguishes it from the sibling tools, which all deal with topics, services, actions, or node/parameter inspection. An agent can immediately identify the purpose and differentiate it from ros2_topic_echo or ros2_call_service.

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 description does not explicitly state when to use this tool versus alternatives. It only describes the action itself. However, the sibling tool list (topics, services, actions, etc.) makes it implicitly clear that this is the only TF-related tool, so an agent could infer its use for coordinate transforms. Still, there is no explicit 'use this when you need the pose of a frame relative to another' or any 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only says it measures frequency and period statistics, but does not disclose that it subscribes to the topic, that it may block until the timeout or sample count is reached, or that it is a read-only operation. There is no mention of potential side effects, prerequisites (like the topic must exist and have active publishers), or behavior when no messages are received. This lack of behavioral detail is a significant gap given the absence of annotations.

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 two sentences: a front-loaded purpose statement followed by a compact Args list. There is no fluff or redundant information. The purpose is stated immediately, and the parameter descriptions are concise and directly tied to the schema. Every word 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?

The tool has an output schema (not shown) which likely defines return values, so the description does not need to explain that. However, it lacks critical usage context: no mention of blocking behavior, that it subscribes to the topic, or that it may take time up to timeout_sec. Since annotations are absent, the description should have disclosed these behaviors. It is adequate for a straightforward measurement but incomplete for a tool that can potentially wait for samples.

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 is the only source of parameter meaning. The Args section adds value by explaining each parameter: 'ROS2 topic to measure', 'Type of message', 'Target number of samples to record', and 'Maximum collection time'. These descriptions clarify that sample_count is a target (not guaranteed) and timeout_sec is a limit. This goes beyond the schema's bare names and types, providing useful context for an agent.

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 states a specific verb 'Measure' and a precise resource: 'publishing frequency (Hz) and period statistics of a topic'. This clearly distinguishes it from sibling tools like ros2_topic_echo (which echoes message content) and ros2_topic_publish (which publishes messages). An agent can immediately understand what this tool does and why it is different from the other topic-related tools.

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 description provides no explicit guidance on when to use this tool versus alternatives. It implies usage through its purpose—if you want to measure publishing frequency, this is the tool—but does not mention alternatives or exclusions. For example, it doesn't say 'use this to check if a topic is publishing at a healthy rate' or 'not for inspecting message content'. The usage context is implied but not stated explicitly.

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 of behavioral disclosure. It states that messages are published in sequence at a given interval, but it does not disclose whether publishing blocks until completion, what happens on invalid JSON or unknown topic types, whether the topic is validated before publishing, or what the return behavior is beyond an output schema that is not shown.

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 compact: one purpose sentence followed by a short Args list. The main idea is front-loaded and there is minimal fluff. The Args list partially duplicates the schema, but it adds enough semantic color to justify its presence.

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?

The description covers the basic operation and parameter meanings, and an output schema exists to document return values. However, without annotations, it lacks critical behavioral context such as blocking behavior, validation, and failure modes. It also does not guide selection among sibling publish/echo tools, leaving an agent to infer some important operational details.

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. The Args list adds basic semantics for each parameter, particularly 'sequence: List of JSON message objects to publish in order,' which is helpful. However, it does not explain how to reference the ROS message type (e.g., package/msg/Type), the expected JSON structure for sequence items, or constraints on interval_sec beyond the schema default.

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 starts with a clear verb and resource: 'Publish a sequence of mock messages to stimulate and test subscriber nodes.' It conveys the core purpose and implicitly differentiates from sibling ros2_topic_publish by emphasizing a sequenced batch of mock messages. It does not explicitly name or contrast a sibling, so it stops short of a perfect 5.

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 phrase 'to stimulate and test subscriber nodes' gives a clear intended context. However, there is no explicit guidance about when to choose this tool over alternatives like ros2_topic_publish, nor any exclusions or conditions such as 'for a single message use ros2_topic_publish.' The usage guidance is implied rather than stated.

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 of behavioral disclosure. It says it records messages for a period and returns stats, but it does not disclose whether the call blocks until duration_sec elapses, whether it writes data to disk, what side effects occur, or what the returned summary statistics cover.

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 short and front-loads the core behavior. The Args list is clean and each line is purposeful, though it partially duplicates parameter names with minimal expansion.

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?

The description is minimally viable for a simple three-parameter tool and an output schema exists, so return values need not be explained. However, with no annotations and no usage guidance, it leaves open questions about execution behavior, topic type formatting, and when this tool is the right choice among siblings.

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 Args section must carry the load. It adds basic meaning: topic is what to record, topic_type is the message type, and duration_sec is in seconds. However, it omits format guidance such as fully-qualified topic names or ROS message type syntax, leaving a meaningful gap.

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 states a specific action, 'Record topic messages for a period,' and a clear result, 'return summary statistics.' This is enough to distinguish it from siblings like ros2_topic_echo or ros2_measure_topic_hz, though it does not explicitly name those alternatives.

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?

There is no guidance on when to use this tool versus the many sibling tools. The description does not mention when summary statistics are preferable to live echo, frequency measurement, or assertion tools, nor does it explain any prerequisites for recording.

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 of behavioral disclosure. It only says 'Set runtime parameters' and does not explain side effects, persistence, permission requirements, failure behavior, or whether parameters are applied atomically or immediately.

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 compact and front-loaded with the core action, and the Args list is clearly structured. There is no filler, though the behavior section could be expanded without harming conciseness.

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 mutation-focused tool with no annotations and no schema-level parameter descriptions, the description under-delivers: it omits side effects, preconditions, node liveness requirements, and failure semantics. The presence of an output schema reduces the need to explain return values, but the missing runtime behavior remains a significant gap.

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 Args block in the description adds useful meaning: node_name should be a full path, and parameters is a key-value dictionary. However, it does not specify value types, units, constraints, or behavior for unknown parameter names, leaving the semantics only partially explained.

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 states a specific verb ('Set'), a clear resource ('runtime parameters'), and a specific target ('a specific ROS2 node'). It does not explicitly differentiate from sibling tools like ros2_get_parameters, but the set/get distinction is self-evident from the wording.

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 description provides no explicit guidance on when to use this tool versus alternatives, and no exclusions or preconditions. Usage is only implied: it is the tool for updating node parameters, not for listing or inspecting them. No conditions like 'node must be running' or 'parameter must already be declared' are mentioned.

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. It does not disclose blocking semantics, timeout behavior (e.g., what happens if fewer than 'count' messages arrive), handling of non-existent topics, or whether it subscribes transiently. The only behavioral hint is the timeout_sec parameter.

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 purpose is front-loaded in a single sentence, followed by a structured Args list with no wasted words. The docstring format is efficient and scannable for an agent.

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?

An output schema exists, so return-value explanation is not required. However, with 0% schema coverage and no annotations, the description should cover edge behavior more thoroughly — specifically timeout behavior, empty-topic handling, and what 'capture' implies about subscription semantics. It covers the basics but leaves operational details to inference.

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% — the schema contains only titles, no descriptions. The description's Args list is the sole source of parameter meaning and covers all 4 parameters with brief but functional definitions, including defaults for count and timeout_sec. Could add format details (e.g., message type syntax) but adequately compensates for the empty 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 states a specific verb ('Capture and return') and resource ('messages from a ROS2 topic'), which clearly identifies the tool's function. It implicitly distinguishes from the publish sibling (receive vs send) and get_topics (sample vs list), though it does not explicitly name any sibling.

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?

No guidance is given on when to use this tool versus alternatives. With 15 siblings including ros2_measure_topic_hz (which also subscribes and samples a topic) and ros2_assert_topic_published, an agent gets no help selecting among overlapping capabilities.

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 of behavioral disclosure. It simply restates the publish action without explaining whether the call blocks, validates the topic type, returns confirmation, or behaves differently on errors. For a side-effecting tool, this is a notable transparency gap.

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 short, front-loaded with the purpose, and each line in the Args block adds real value. There is no filler or redundant restatement of 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?

For a simple three-parameter publish tool, the description covers all required inputs with examples, and the presence of an output schema reduces the need to document return values. It remains light on usage context and runtime behavior, but the essential invocation information is present.

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?

With 0% schema description coverage, the Args block provides the necessary meaning for every parameter: topic is a ROS2 topic name, topic_type is a message type string, and data is the JSON object/dict payload. The examples for topic and topic_type are concrete and useful, though data could better explain how fields map to the message type.

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 states a specific verb and resource, 'Publish a message to a ROS2 topic', which clearly separates this from inspection tools like ros2_get_topics or ros2_topic_echo. It does not explicitly differentiate itself from sibling publishing tools like ros2_mock_publish_sequence, so it falls just short of full distinction.

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 description provides no guidance on when to use this tool versus alternatives. It does not mention that ros2_assert_topic_published is for verification or that ros2_mock_publish_sequence is for publishing sequences, so the agent must infer selection from sibling names alone.

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