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

Discloses behavior: executes commands one by one, returns ok/results/errorCount/stoppedEarly/saveStatus, and no retry on timeout. No annotations exist, so description carries full burden; side effects are not detailed but inherent to command execution.

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?

Description is a compact bullet-like list of parameter meanings, directly relevant and without fluff. It effectively conveys the necessary information in a structured manner.

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?

Provides output field names and some edge-case behavior, but lacks details on 'host', 'save' semantics, and the output schema structure is not fully elaborated. Gaps exist for full context, though core usage is covered.

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?

Many parameters are explained (target, view, username/password, new_password, stop_on_error, confirm), but 'host' and 'save' are not described at all, and 'commands' is implied only. Schema coverage is partial, leaving clear gaps.

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?

Description clearly states it executes commands on a started eNSP device console, with a specific verb and resource. It does not explicitly compare to sibling tools like device_push_config, but the action is distinct enough from context.

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 parameter guidance (target, view, credentials, confirm, stop_on_error) and notes that timeout disconnection will not retry commands. However, it does not explicitly state when to prefer this tool over alternatives.

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 must carry the full behavioral disclosure. It does so by noting that on command failure or timeout no config file is written, and by detailing the diff output variants (identical, onlyOnDevice, onlyInFile, unifiedDiff with context, preserving line order and duplicates). This adds real behavioral context beyond what any schema would show. It does not mention permissions or side effects, but the failure/timeout note is a strong positive.

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 three sentences: the first states the core purpose and the two optional parameters, the second details the diff behavior, and the third notes failure behavior and the login-parameter reference. It is front-loaded and free of fluff, though the third sentence could be merged to reduce length slightly.

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 8 parameters and an output schema, the description covers the main operation, the diff output, and failure behavior, but leaves most parameter semantics to inference or a sibling reference. Since an output schema exists, return-value documentation is not required, but the lack of explanation for 6 parameters makes the tool only partially 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, but it only explains two of eight parameters: save_to (writes a UTF-8 file) and compare_with (compares with a baseline). The remaining parameters (host, target, username, password, topo_path, new_password) are not explained; the note that login parameters are same as device_exec is a reference, not an explanation. This leaves most parameter semantics undefined.

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 clear verb-object pair ('读回运行配置' = read back running config), states the resource and core operation, and immediately adds optional save/compare capabilities that distinguish it from siblings like device_push_config (which pushes configs). This gives an agent a precise idea of the tool's role.

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 (whenever you need to read a device's running config) but never states explicit alternatives or exclusions. It references device_exec for login parameters but does not say 'use this instead of X' or list conditions that would make another tool preferable. The guidance is adequate but not directive.

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?

Without annotations, the description explains response behavior: ping returns stats and reachable (null if parsing fails), other actions return raw output, and ok indicates command execution status. It also clarifies that connectivity is determined via parsed.reachable. This provides substantial transparency about expected outputs, though it doesn't address side effects or rate limits.

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, starting with the core purpose and action list, then adding conditions for ping/tracert and response interpretation. It's efficient but could be better structured with explicit sections, though it avoids unnecessary fluff.

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 tool has 9 parameters, no annotations, and 0% schema description coverage, the description is incomplete. It doesn't explain all parameters, doesn't provide usage examples or comparisons with siblings, and only partially describes returns. An agent would need to infer several aspects, making it insufficient for reliable 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 schema has no descriptions (0% coverage), so the description must clarify parameters. It only explains destination (required for ping/tracert) and count (1-100), and mentions login params are same as device_exec. It leaves target, topo_path, and new_password unexplained, which is insufficient for an agent to correctly fill all 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 clearly defines the tool as a device connectivity and status query tool, enumerating specific actions (ping, tracert, interfaces, etc.). This distinguishes it from sibling tools like device_exec which executes arbitrary commands, making its purpose 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 gives a condition for ping/tracert requiring destination and mentions login parameters are shared with device_exec, but it doesn't explicitly state when to use this tool versus alternatives or provide exclusions. It implies usage for network diagnostics but leaves the decision to the 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?

With no annotations provided, the description carries the full burden. It discloses key behaviors: automatic entry into system view, handling of #-segmented display current-configuration text with sub-view exit/re-entry, default stop-on-error and no-save behavior on errors, no automatic rollback, commit-before-save when CE prompt indicates uncommitted changes, and failure status on save exceptions. This is thorough, though it could clarify the interaction between the 'save' default and error-path behavior more explicitly.

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, using a few sentences to convey a wealth of information. It front-loads the core purpose and constraint, then follows with behavioral details. It is dense but not verbose, and each sentence adds value. The structure is logical, though it could benefit from bullet points for scannability.

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 tool's complexity (10 parameters, no annotations) and an output schema that likely covers return format, the description covers most essential behaviors and the key config-file constraint. However, it omits explanations for several parameters and does not mention error handling specifics beyond save failures. It is adequate but not fully complete for an agent to call it confidently in all edge cases.

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 clarifies the exclusivity of config/config_file, references device_exec for credential parameters, and states save's default. However, it does not explain host, target, topo_path, or stop_on_error beyond the implicit mention. While these may be inferable from names, the description fails to fully document all ten parameters, leaving gaps 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 clearly states the tool pushes configuration from text or a UTF-8 .cfg file, with a precise constraint that config/config_file must be chosen exclusively. This distinguishes it from siblings like device_fetch_config (fetch) and device_exec (execute commands). The verb 'push' and resource are specific, making the purpose unmistakable.

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 mentions that username/password/new_password are the same as device_exec, hinting at shared context, but does not explicitly state when to use this tool versus device_exec or device_fetch_config. There are no clear exclusions or conditional routing cues, leaving the selection logic mostly to the agent's inference from the purpose.

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 full responsibility. It discloses background behavior (idle connections reclaimed every 30 seconds, closure on service exit) and that close operations wait for running commands to finish. This is valuable beyond the schema, though it omits potential error conditions or side effects on list operations.

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 well-structured: a clear purpose sentence, then action details, target explanation, and background behavior. It is not overly verbose and each sentence adds value, though it could benefit from a line about host or a clearer action-target mapping.

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 usage for list and close actions and explains the background lifecycle, which is helpful. However, it omits the host parameter, does not specify the behavior of close_all beyond its name, and relies on the output schema for return details. There are minor gaps that could confuse an agent when dealing with host-specific sessions or close_all semantics.

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 'action' values and clarifies that 'target' is the port number for close, but it does not explain the 'host' parameter at all. It also leaves ambiguity about whether close_all requires a target. Partial coverage of the three parameters, with the most critical ones addressed.

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 purpose: to view or close console sessions, listing the specific actions (list/close/close_all). It names the resource (console sessions) and distinguishes this from sibling tools focused on topology or device configuration, so an agent can identify it accurately.

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 for managing sessions but does not explicitly state when to choose this tool over alternatives like device_exec or topo_* tools. It provides action semantics but lacks explicit 'when not to use' guidance or conditions that would route the agent to a sibling. This is adequate but not explicit.

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?

由于没有注释，描述承担了行为披露责任。明确说明'只读'且'不启动或修改任何虚拟机'，这是关键行为信息。但未说明错误处理、权限需求或失败时的表现，如检查失败是否抛出异常或返回何种状态。

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?

工具较复杂（3个可选参数），有输出schema但未提供。描述覆盖了检查内容和结果判断，但未说明输出结构细节（如是否包含其他字段）或潜在错误场景。鉴于输出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?

schema描述覆盖率为0%，描述必须补偿。描述对每个参数提供了详细语义：path指定.topo文件用于按实际型号判断，models为计划型号列表且可与path合并，ensp_home指定安装目录并说明省略时的查找逻辑。这远超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?

描述明确指出这是一个只读环境检查工具，具体检查eNSP、VirtualBox、模板机和设备镜像，并列出检查项（VirtualBox版本、Hyper-V/VBS冲突等）。动词'检查'和资源明确，与兄弟工具（拓扑操作和设备操作）区分度高。

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?

描述提到'还没创建拓扑时可先检查'，并解释readyForTopology表示前置条件满足，暗示应在拓扑创建前使用。但未明确说明何时不使用或与其他工具（如topo_validate）的替代关系，仅有隐含的使用场景。

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 transparency burden and does disclose the optional topo_path consistency-check behavior. It does not explicitly state that the operation is read-only, although the wording '列出' and '核对' strongly imply no mutation.

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 main purpose, followed by usage context and parameter details. It avoids unnecessary verbosity while still conveying actionable guidance.

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 simple three-optional-parameter interface and no annotations, the description is complete enough for an agent to decide when to call the tool and what to expect. It also ties the output to the sibling topo_connect workflow.

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?

Although the input schema has no parameter descriptions, the tool description compensates by explaining all three parameters: category values and blank behavior, model filtering and full-interface-list behavior, and topo_path validation 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 clearly identifies the tool's purpose: listing eNSP-supported device models and their interface inventories. It also distinguishes the tool from sibling topology operations by positioning it as the pre-topology lookup for model and port names.

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 to call this before building a topology and that fromPort/toPort values in connection operations should use the interface names returned here. The parameter-specific guidance for category, model, and topo_path makes when and how to use the tool 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 present, the description carries the transparency burden and does reveal important side effects: it adds devices batch-wise and auto-assigns console ports without conflicts. It does not mention failure modes, whether the topology file is modified/overwritten, idempotency, or what happens on invalid model/settings, so some behavioral aspects remain opaque.

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 uses a clean Args list, bullet sub-fields, an example block, and a one-line port note. It is compact, scannable, and free of redundant filler, making it easy for an agent to extract the necessary information quickly.

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 largely self-contained: it defines all device fields, references list_models for model details, and mentions topo_layout for coordinate placement. It does not state what the function returns or explicitly reference sibling add/remove tools, but the included examples and port behavior make it sufficient for common use.

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?

Although the JSON schema only has bare path and devices fields, the description fully documents the meaningful sub-fields (model, name, count, x/y, settings), marks model as required, gives defaults for name/count, and provides concrete examples. This goes well beyond the schema and removes ambiguity about the devices array's structure.

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 object: '批量加设备' (batch add devices) to a topology, and the parameter examples clarify the operation. It clearly distinguishes from siblings like topo_layout and list_models by focusing on the add action, so an agent can identify the tool's purpose 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 description provides practical examples and a useful note about console-port auto-allocation from 2000 without conflicts. However, it never explicitly states when to prefer this tool over siblings such as topo_create or topo_remove, leaving some selection guidance implicit.

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 transparently states that omitted ports auto-select the first free one, line type defaults based on interface type, and duplicate interface usage raises an explicit error naming the offending port. This is exemplary behavioral transparency.

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 well-structured with bullet points and an example, front-loaded with the purpose. It is a bit lengthy but every sentence adds value, explaining defaults and error behavior. No 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?

The description covers all necessary aspects for an agent to call the tool correctly: parameter semantics, defaults, error handling, and a practical example. Even though an output schema exists, the input description is fully self-sufficient.

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 description fully compensates by explaining both parameters in detail. It describes the path parameter, the structure of links with required and optional fields, accepted port formats, defaults, and provides a concrete example. This exceeds what a schema could convey.

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 performs batch connection of links in a topology file ('批量连线'), and the detailed explanation of links and their fields distinguishes it from sibling tools like topo_create, topo_layout, or topo_inspect. The purpose 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 provides a comprehensive example and explains how optional fields behave (auto port selection, auto line type detection), making it clear when and how to use it. It doesn't explicitly mention when not to use it or alternatives, but the context of sibling tools makes the intended usage evident.

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 must disclose behavioral traits. It mentions the overwrite parameter and its default behavior, but does not explain what happens if the file already exists and overwrite is false (error or skip), nor does it describe success/failure outcomes or any side effects. For a file-creation tool, this is a significant 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 concise, with the purpose stated in the first sentence and parameter details following in a structured list. It is front-loaded and contains no filler. Minor redundancy in saying 'empty' but it adds clarity. Overall efficient.

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?

Despite having an output schema, the description does not explain what the tool returns (e.g., success indicator, file path). It also omits error handling, permission requirements, or edge cases like invalid paths. For a simple creation tool, this is incomplete; an agent would need to guess expected outcomes.

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 clear explanations for both parameters: path specifies the destination and overwrite controls overwriting behavior with a default. This adds meaning beyond the bare schema definitions, though it could be slightly more detailed (e.g., path format validation).

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 creates a new empty .topo file, using a specific verb ('新建' meaning create) and resource. This distinguishes it from sibling tools like topo_add_devices or topo_connect, which modify existing topology, and topo_inspect which reads. The purpose is 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?

No explicit guidance on when to use this tool versus alternatives. The description only states what it does, not when it should be invoked. There is no mention of prerequisites, exclusions, or alternative tools, leaving the agent to infer usage from the action itself.

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 discloses that omitting out_path returns content instead of writing to disk, and that CSV output produces two files with suffixes. However, it doesn't mention permissions, side effects, or whether the operation is read-only. Since this tool writes files, it's a potentially mutating action, and the description should note any requirements (e.g., write access).

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 organized into three bullet-like lines for the arguments. It front-loads the main purpose and then details parameters efficiently. No wasted words, though it could be slightly more structured with a brief example.

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 an output schema (not shown) which likely describes return values, so the description needn't cover that. The description covers parameter semantics and file-writing behavior. It lacks error scenarios or edge cases (e.g., what happens if format is invalid), but for a simple export tool, this 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?

Schema description coverage is 0%, so the description is the only source of parameter meaning. It fully explains path (file path), format (with values and their meanings), and out_path (output file path, optional, with CSV splitting behavior). This is exemplary compensation for the sparse 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 purpose: exporting a topology into document-ready formats. It lists three concrete formats (mermaid, drawio, csv) and specifies what each yields. This distinguishes it from sibling tools like topo_inspect or topo_render, which are inspection/rendering rather than export.

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 explains what each format is for (flowchart source, draw.io import, CSV device/link tables) and how out_path behaves (omitting it returns content instead of writing). It doesn't explicitly say when to prefer this tool over siblings, but the export intent is clear enough that an agent would know to use it for output generation.

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 indicates a read-only operation ('读') and describes the returned data, but it does not explicitly state that no modification occurs, nor does it cover edge cases like missing files or error behavior. The note about consolePort adds useful context for downstream usage, but the description is not exhaustive.

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 with zero waste. The primary action and outputs are stated first, and the second sentence adds a crucial, actionable detail (consolePort mapping) without redundancy. It is concise and well-structured.

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 the tool has an output schema (not shown) and a single parameter, the description provides enough context for correct invocation: it explains what is read and what is returned, and even how to interpret a key field (consolePort). It does not mention error conditions or file prerequisites, but those are not essential for an inspection tool with a simple interface.

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 for the single 'path' parameter, so the description must compensate. It does so by specifying that the path points to a '.topo' file, which clarifies the expected format. This is sufficient for an agent to understand the parameter's meaning, though it doesn't elaborate on path resolution or validation.

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 verb ('读' = read), the resource (a .topo file), and the specific outputs (device list, link list, free interfaces per device). It also distinguishes itself from sibling tools like topo_create or topo_layout by focusing on inspection, and even ties its output to device_* tools via consolePort, making its role 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 provides clear context on when to use this tool: to inspect a .topo file and retrieve device/link/interface data. It also hints at how to use the output with device_* tools via consolePort, which gives practical usage guidance. However, it does not explicitly state when not to use it or mention alternatives, so it stops 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?

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: default mode is layered, defaults for missing parameters (root picks most connected device, columns uses square root), zones override other layout params, replace_annotations defaults to false to avoid overwriting due to unstable eNSP annotation IDs, include_unassigned defaults true, and allow_annotation_desync defaults false. It also explains why certain defaults exist (annotation ID instability). However, it doesn't explicitly state what happens to existing device positions when layout is applied (does it move all devices? only some?) or whether it returns any success/failure info, though the output schema may cover that. Slight gap but not a contradiction.

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 comprehensive but well-organized: starts with a one-line purpose, then breaks down each parameter with clear formatting (indented bullets and lists). It is longer than necessary for a simple tool but given the 10-parameter complexity, the structure is appropriate. It front-loads the core purpose and then details parameters in logical order. No redundant sentences, but could be slightly tightened (e.g., mode list could be more compact). Still, it earns high marks for structure.

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 complex tool with 10 parameters, 0% schema description coverage, and no annotations. The description covers every parameter, all modes, interactions, defaults, and safety concerns (annotation handling). It addresses edge cases (unassigned devices, annotation desync, default refusal to overwrite). Given the complexity, the description is remarkably complete – an agent can confidently select the right parameters and understand the tool's behavior without needing external info. The output schema exists, so return values are likely covered there.

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 fully compensate. It does: each parameter gets a detailed explanation of its effect, valid values (mode enum with descriptions), constraints (only in certain modes), defaults, and examples (groups example). It also explains interaction between parameters (zones override mode/groups/root/columns). The description adds substantial meaning beyond the bare schema types, making it easy for an agent to know exactly what to pass.

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 automates device coordinate layout, avoiding manual x/y entry. It explicitly contrasts with manual placement and names the resource (.topo file). The verb '排布' (arrange/layout) plus '设备坐标' (device coordinates) and the distinction from manual entry make the purpose 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 provides extensive usage guidance: it explains each mode with concrete scenarios (layered for typical campus networks, tree from root, grid for pre-connection, ring for ring networks), clarifies parameter applicability (groups only in layered, root only in tree, columns only in grid), and gives explicit when-not-to-use guidance (e.g., 'avoid overwriting annotations unless needed'). It even warns about annotation desync and default refusal, covering both when and when-not to use specific flags.

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 present, so the description must carry the full burden. It discloses a key side effect: deleting a device also deletes all its associated links. It does not mention other effects like confirmation or rollback, but the main destructive 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 extremely concise, starting with the core action, then listing parameter meanings in a clear bullet-like format. Every sentence adds value without 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 simple destructive tool, the description covers the main action, parameter meanings, and a crucial side effect. It does not detail return values or error handling, but these are likely secondary given the tool's scope.

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 provides no descriptions, so the description adds meaning. It explains `devices` as names whose deletion cascades to links, `links` as pairs to disconnect, and `path` as a .topo file path. This covers all three parameters even though it is brief.

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 explicitly states the tool removes devices or links, which is a clear verb-resource pair. It does not name sibling tools for contrast, but the intent is unambiguous in the context of topology editing.

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 for deletion/disconnection but does not explicitly contrast with `topo_add_devices` or `topo_connect`. The cascade behavior gives some context, but clear when-to-use vs. alternatives is 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states limitations ('PNG is not eNSP native, cannot prove devices start') and provides practical guidance on the 'scale' parameter. It doesn't describe error handling or file creation behavior, but covers the core behavioral aspects relevant to an 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?

The description is concise and front-loaded with the core purpose. Each sentence adds value: purpose, limitations, and parameter explanations. It's slightly verbose but not wasteful, and the structure (purpose → limitations → args) is logical.

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 render tool with 4 parameters, the description covers purpose, usage context, parameter semantics, and key limitations. It doesn't detail the output format beyond 'PNG' but that's sufficient given the output schema exists. The description is complete enough for an agent to decide when and how to use 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 fully compensate. It explains all four parameters: 'path' (file path), 'out_path' (default same name and directory with .png extension), 'scale' (increase to ~1.5 when crowded), and 'show_ports' (whether to mark interface names, default on). This adds significant meaning beyond the bare schema and includes usage hints.

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 purpose: 'draw the topology as an auxiliary PNG' with a specific verb and resource. It distinguishes itself from siblings by noting it's not eNSP native and not for validation, so an agent can immediately understand its scope.

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 context: it's optional, for quick visual inspection without opening eNSP, and explicitly states that normal diagram creation and acceptance processes do not depend on it. While it doesn't name alternative sibling tools, it effectively implies when to use it (for rough layout preview) and when not (for validation).

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 burden. It discloses the scope of validation (specific check list) and severity interpretation. It implies read-only behavior (validation) but does not explicitly state it makes no modifications or require file format details. Still, it provides meaningful behavioral context beyond the schema.

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 well-structured: first sentence gives usage recommendation, second explains error/warning severity, third lists specific checks. No filler, front-loaded with the key recommendation, and every sentence adds 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?

Given there is an output schema, return format is covered. The description explains when to use, what is checked, and severity. The only gap is the meaning of 'path' parameter, which is a single required field. Overall, it is nearly complete for a validation tool with a simple parameter list.

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% for the only parameter 'path'. The description does not explain what 'path' refers to (e.g., file path, directory, format). With zero schema description and no clarification, the agent cannot infer the correct value format, so this dimension is poorly served.

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 validates a topology for problems before opening in eNSP, and lists specific checks (duplicate names, interface range, multi-connections, console conflicts, isolated devices, overlaps, model risks). This distinguishes it from siblings like topo_inspect or topo_layout by its validation role and pre-eNSP usage context.

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 recommends running before opening in eNSP and distinguishes errors (must fix) from warnings (reminders). This gives clear when-to-use context. However, it does not mention when not to use it or point to alternatives like topo_inspect for detailed inspection, leaving room for improvement.

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