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

There are no annotations, so the description carries the full transparency burden. It clearly discloses that the tool runs arbitrary shell commands, is not vetted by any whitelist, and should be used cautiously. It does not mention every possible side effect, but for a generic exec tool the core risk profile is explicit.

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 short sentences, front-loads the core capability, provides usage examples, and then adds the important safety warning. There is no filler or duplicated schema 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?

Given a one-parameter schema and the existence of an output schema, the description is operationally complete: it specifies the execution location, command generality, intended use, and no-whitelist risk. Nothing else is necessary for correct 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?

Schema description coverage is 0%, yet the description fully compensates for the single parameter: command is explained as '任意 shell 命令' and supported with concrete examples like rostopic pub and catkin_make. For a one-parameter tool, this is complete semantic guidance.

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, resource, and scope: execute arbitrary shell commands inside the container. It also labels the tool as a general fallback, which makes its role immediately distinguishable from sibling status/inspection tools and from ssh_exec.

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?

It gives concrete usage signals with examples such as rostopic pub and catkin_make, and calls itself a fallback tool used for temporary operations. It implicitly says to prefer dedicated tools first, but it does not explicitly name alternatives or 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?

There are no annotations, so the description carries the burden of behavioral disclosure. It states that matching uses pgrep -f on the host, which reveals the matching mechanism and that this is a read-only process lookup. It also clarifies that arbitrary keywords are allowed, not just the predefined service names, which guards against an agent assuming the input is restricted.

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?

Two dense sentences contain all essential information: purpose, mechanism, known valid values, and extensibility. There is no repetition, filler, or redundant restating of the tool name or 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?

Given the output schema exists, the description does not need to explain return values. It covers what the tool does, how matches are performed, and what inputs are valid. It does not discuss edge cases like no match found or invalid keyword syntax, but for this single-parameter read-only status tool the provided context is adequate.

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 schema has 0% parameter description coverage, but the description compensates effectively by explaining that the 'service' parameter is a process keyword passed to pgrep -f, listing known valid values, and clarifying that arbitrary keywords also work. This makes the single parameter understandable and safely usable.

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 a specific action (querying whether key project services are running), identifies the target resource (host processes via pgrep -f), and provides known service names. This distinguishes it from sibling tools like ros_topic_status and tmux_status, which concern completely different environments.

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 tells the agent exactly when to use this tool: for checking host-level process/service status with pgrep -f matching. It names the accepted known services and explicitly allows passing an arbitrary keyword, giving a clear usage pattern. It does not explicitly exclude the sibling status tools, but their domains are otherwise clear.

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 disclosure burden. It reveals significant beyond-schema behavior: known service names automatically resolve to latest log files, and arbitrary container paths are allowed. The containerized scope and the lines range are also clear. It does not mention error behavior or side effects, but it does cover the non-obvious automatic resolution and path flexibility.

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 core purpose is stated first, and the rest is a compact list of known services, an alternative usage mode, an example path, and a constraint. Every line is informative and there is no filler. It remains concise while providing exceptional detail.

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 two-parameter read tool with output schema, required context is present: service meaning, known aliases, file path behavior, operation scope, line limit, and example path. There is no gap that would prevent the agent from correctly selecting and invoking this tool. The output schema suffices for response variety; so nothing significant 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?

Since the input schema lacks descriptions, the description fully compensates: it explains that 'service' may be a known name or a container path, gives two concrete aliases and a path example, and states the valid lines range. This is exactly the kind of meaning the schema itself cannot provide, so the compensation is nearly total.

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?

Reads project log tail content, which exactly matches the tool name and resource. It clarifies the operation focuses on log tail in the container and distinguishes the tool from all siblings in the list, which handle exec, tmux, process checks, or ROS topics. It is specific and unambiguous.

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 clearly gives a duality of usage: pass one of the two known names to auto-discover the latest log, or pass an explicit container path. It also states valid bounds for lines. The only weakness is it never explicitly addresses when to choose this tool over an alternative such as tmux_capture or exec_cmd, so it falls short of full 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?

With no annotations present, the description carries the full burden and it does well: it reveals the destructive sequence (kill then start), the safety confirm-lock that prevents accidental kills, and the required post-restart verification. It doesn't spell out side effects like failure modes or the impact of killing an active node, but it is transparent enough for safe 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?

Every sentence earns its place: purpose, supported service, safety rule, and verification step. The description is compact, well-structured, and front-loaded with the tool's core behavior before safety and follow-up notes.

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 that this is a simple two-parameter destruction tool with an output schema, the description covers all essential operational context: what it does, how to safety-confirm it, which service is supported, and how to verify success. It also complements the sibling list by pointing to ros_topic_status as the required validation channel. Nothing an agent needs to invoke 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?

Because schema description coverage is 0%, the description must explain the parameters. It does so for both: 'confirm' must be explicitly True, and 'service' is exemplified by 'ego_planner' (obj_nav.launch). It doesn't enumerate all possible service names, but it clearly states the currently supported one, which is sufficient for the current one-service scope.

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 action — restart a critical ROS service — and the exact mechanism: kill process first, then start in background. It also names the currently supported service (ego_planner with obj_nav.launch), making it unambiguous what resource this tool acts on and distinguishing it from sibling status/exec 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 gives clear usage context: it is the tool for restarting the supported 'ego_planner' service, the confirm parameter is a mandatory safety gate, and the agent is instructed to verify via ros_topic_status after the restart. It does not, however, explicitly say when not to use it or contrast it with exec_cmd/ssh_exec as an alternative, so it misses the when-not/alternative dimension by one level.

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?

There are no annotations, so the description carries the burden. It reveals meaningful behavioral traits: it returns the latest n messages, uses --noarr to exclude array fields, and restricts n to 1–5. While it does not mention error behavior or side effects, the read-only nature is evident from the verb '读取', and the explicit exclusions add useful context.

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, with just two sentences. The main action and key constraints are front-loaded, and the example topics are useful without extra fluff. Every sentence contributes either to clarity or to parameter understanding.

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 complete enough for a command-line echo tool, especially given that an output schema exists to define return values. It covers the purpose, the important flags, the n range, and examples for the required parameter. It stops short of explaining failure modes or prerequisites like needing an active ROS environment, but those are unlikely to be essential given the simplicity and output schema.

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 input schema provides zero description coverage, so the description must compensate. It does so by explaining the meaning of n ('最新 n 条消息') and its range (1–5). It also gives examples for the 'topic' parameter, clarifying the expected format and usage. However, it does not fully define the topic string boundary conditions, which leaves a small 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 clearly states the primary action: '读取 ROS 话题最新 n 条消息' (read the latest n messages from a ROS topic). It also specifies the --noarr flag and gives concrete example topics, making the resource and scope unmistakable. It does not explicitly name an alternative sibling, but it is sufficiently distinct from the other tools in the list.

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 offers use-case guidance via example topics ('用于查看 /bridge/Instruct、/agent_run/log 等话题内容') which implies when this tool is appropriate. It does not provide explicit 'when not to use' or direct comparisons to alternatives such as ros_topic_status, so the guidance remains implied rather than fully explicit for an agent.

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?

描述直接说明了执行的具体命令 (`rostopic hz -w 5` 与 `rostopic echo -n 1 --noarr`)，这比仅说“查询状态”更具透明性。在无 annotations 的情况下，它补充了实际行为、容器内执行和示例话题，可让agent预知操作和影响，只是未详细谈延迟或失败模式。

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?

描述紧凑且信息密度高：第一句即说明工具目的，随后给出底层命令、参数格式和真实用例。没有冗词，所有句句都有价值。

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?

该工具参数少、行为简单，描述覆盖了核心所需：命令、参数、示例和成功判断。已有输出 schema 可承载返回值信息，因此描述无需再解释返回格式。整体对agent调用已足够完整。

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 只写着 topic: string，没有任何说明，schema_description_coverage 为 0%。描述对此做了补偿：指出这是完整话题名，并给出具体示例。对于一个参数的工具，这足以让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?

描述明确了操作：查询 ROS 话题状态，并说明输出是采样频率(hz) 和最新消息摘要，这比工具名更具体。虽然与兄弟工具 ros_topic_echo 没有明确对比区分，但从用途上可以判断它面向状态/频率检查而非持续 echo，因此足够清晰。

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?

描述了适用场景：验证 ego-planner 重启是否成功，并给定了判断标准（occupancy 有 hz 即成功）。这为agent提供了明确的上下文，虽然没有明确排除替代工具，但已经超过模糊用法，符合“clear context, no 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 behavioral burden well: it discloses how host is resolved via ~/.ssh/config, that password mode uses sshpass with the password only via an environment variable, and that timeout applies to the remote command. Minor gaps remain, such as stderr/exit-code handling, but the core behavior is 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 efficiently structured: a one-sentence purpose, followed by short bullets for host notes, authentication and timeout. Every sentence contributes useful information with no fluff 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 tool with no annotations and no schema parameter documentation, the description is complete: it covers host targeting, auth paths, timeout semantics, and the shell-command/return-output model. An agent can safely construct a correct 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 schema has zero description coverage, so the description fully compensates. It explains host with two concrete formats, command as a shell command, timeout as a seconds default of 60, and password as the switch to password authentication. This adds meaning 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 opens with a specific action: executing shell commands on a remote host and returning output. The 'remote host' wording differentiates it from local execution tools like exec_cmd, and the concrete host format examples make the resource unambiguous.

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?

It gives clear context for use: remote host execution with host alias or user@ip formats, default key-based or password-based auth, and a configurable timeout. It does not explicitly name sibling tools or state exclusions, but the remote-host scope is an adequate differentiator.

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 full weight. It clearly indicates the tool reads ~/.ssh/config and returns structured connection info, and it frames the behavior as a pre-flight lookup rather than a connection action. This is sufficient for a simple read-style utility, though it does not mention potential errors like an absent config file.

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, scannable, and front-loaded with the action and resource. The second sentence lists return fields and the intended downstream use, all without 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?

Given the zero-parameter interface and an existing output schema, the description is nearly complete for invocation. It explains where data comes from, what fields are returned, and how the result relates to ssh_exec. It could add an edge case note about a missing config file, but nothing necessary for correct invocation 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 has zero parameters, so the description cannot benefit from or contradict the input schema. It indirectly explains the main data being produced (host connection fields), which is useful context. With no parameters, schema coverage is trivially complete and the description 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?

Uses a specific verb ('列出') with a concrete resource (~/.ssh/config) and enumerates the exact returned fields (alias, HostName, User, Port, IdentityFile). It also ties the purpose to 'ssh_exec', which distinguishes it from neighboring tools like ros_topic_* or exec_cmd.

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?

States the primary use case: discovering which hosts are available for direct connection with ssh_exec. This gives the agent a clear trigger condition. It does not explicitly mention when not to use it or name alternatives, but the relationship with ssh_exec is clearly implied.

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?

There are no annotations at all, so the description carries the full burden of behavioral disclosure. It does disclose the core behavior — grabbing the most recent `lines` of the current pane output, bounded to 10–2000 — but it never explicitly states that the operation is read-only/side-effect-free, nor does it address behavior for missing sessions or out-of-range 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?

The three short sentences are all informative and free of filler: the first states the action and scope, the second gives the motivating use case, and the third conveys a parameter constraint. The key scoping information is front-loaded immediately.

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 only two parameters (one required) and an output schema, so the bar is modest. Even so, given complete absence of annotations, the description omits useful context: what happens when a session doesn't exist, whether the operation is indeed read-only, and why it should be chosen over siblings like tmux_status or read_log. It's usable but not fully self-contained.

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 partially does: it clarifies that `session` refers to the tmux session whose pane is captured, and it adds a critical constraint for `lines` (valid range 10–2000) that the schema does not express. This is genuine value-add beyond the raw integer 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 action — 'capture the current pane output of a named tmux session (back `lines` lines)' — with a clear verb and resource. It also gives a concrete use case (viewing live service logs like ego-planner/agent_run) that implicitly separates it from siblings such as tmux_status or read_log, though it never names those alternatives explicitly.

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 clearly identifies the scenario when the tool is appropriate: to inspect continuous logs that a service writes to a tmux pane. It does not, however, state when not to use it or contrast it with the alike siblings (e.g., using read_log for file-based logs or tmux_status for session status checks), so explicit exclusions are missing.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It adequately reveals that the tool may create sessions, that it never kills sessions, and that it uses C-c to stop old programs before sending new start commands. This addresses the main side effects and de-risks agent usage. It does not mention the effect of the 'enter' parameter, but the core behavior is well 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?

The description is brief, front-loaded with the primary action, and then lists relevant reuse rules in a structured manner. Every sentence contributes substantive guidance with 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?

Given that an output schema exists, return values need not be described. The description covers the core call scenario, the missing-session edge case, and the operational constraints needed to execute correctly. Combined with the schema's parameter names, this is sufficient for an agent to invoke the tool safely.

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 explains 'session' and 'command' implicitly by their names and the tool's purpose, but never describes the 'enter' parameter, which is crucial because it determines whether a newline is sent after the command. This leaves a meaningful semantic 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 verb and resource: 'send keys/command to the specified tmux session'. It also clarifies the behavior when the session does not exist. This clearly differentiates from sibling tools like tmux_status and tmux_capture, which are about inspecting state rather than sending input.

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 clear behavioral usage rules: auto-creates a detached session when missing, never kill-session, and sends C-c before restarting a program. This gives the agent practical guidance on how to use the tool safely, though it does not explicitly contrast use cases with alternatives like exec_cmd or tmux_capture.

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?

There are no annotations, so the description carries the behavioral burden. It discloses a read-only listing action, specifies the output scope (all host tmux sessions), and names the resulting fields. It stops short of edge cases such as what happens when tmux is not running, but the main behavioral surface is clear.

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 short sentences with no filler. It front-loads the core operation and output details, then adds a concrete use case.

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 zero-parameter listing tool, the description is complete: it states what is being listed, what the result contains, and which in-environment sessions it helps confirm. An agent has enough information to select and invoke 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?

The tool has zero parameters, so the input schema already covers everything. There is nothing for the description to add, and the baseline for 0-parameter tools applies.

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 and resource: '列出宿主机所有 tmux 会话' and enumerates the returned fields (名称/窗口数/创建时间). It also frames the main use case, distinguishing it from sibling tools like tmux_capture and tmux_send.

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?

It explicitly says the tool is for confirming whether specific tmux sessions like sim_bridge, ego-planner, agent_run, and fake_prompt exist, giving clear context on when to use it. It does not explicitly enumerate exclusions or compare with alternatives, so it is not a full when/when-not guide.

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