Validate network topology files before opening in eNSP. Detects errors that cause launch failures and warnings like device conflicts, interface issues, and overlapping elements.
检查拓扑有没有问题，建议在交给 eNSP 打开之前跑一次。
errors 会让 eNSP 打开异常或链路失效，必须改；warnings 只是提醒。 查的内容包括：设备重名、接口序号越界、一个口接了多条线、 console 端口冲突、孤立设备、图标/文字/背景框重叠，以及条件型号风险。
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.2.0Does 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.