Skip to main content
Glama

ensp_cross_validate_topology

Cross-validate a .topo file against LLDP neighbor scans to detect mismatched interfaces, missing links, or outdated records before config deployment.

Instructions

.topo 文件解析结果与设备 LLDP 邻居做交叉验证。

这是「拓扑纠错」的核心入口——ensp_parse_topology 只看拓扑文件, 而 ensp_verify_lldp_neighbors 反映物理事实。两者不一致时就是 拓扑图错位 / 线缆未接 / 对端设备未启 / 老拓扑需要更新等问题的信号。

工作流程:

  1. 解析 topo_path(XML 或 ZIP 自动识别)

  2. 接收 lldp_results(每台设备调 ensp_verify_lldp_neighbors 返回的 scan 字段或整个返回对象)

  3. 对每条边做双向比对:

    • matched.topo 和 LLDP 都看到的连线(接口端点完全一致)

    • topo_only.topo 记录了但 LLDP 没看到(线没接 / 对端未启 / LLDP 未使能)

    • lldp_only:物理上接了但 .topo 没记(拓扑图过时)

    • mismatched:两端点都对得上,但至少一个接口号错位(拓扑图错位)

  4. 输出结构化 JSON + Markdown 报告,便于 LLM 直接理解和用户存档

参数:

  • topo_path.topo 文件绝对路径

  • lldp_results:列表,元素为 ensp_verify_lldp_neighbors 的返回 (建议传 scan 字段;为了容错,传整个返回对象也可)

  • device_aliases:可选,把 LLDP 的 system-name 映射到 .topo 里的设备名(如 {"AR1": "R1"}),处理 sysname 与拓扑名不一致的情况

典型使用场景:

  • 生成配置前验证接口号:调用本工具确认 .topoGE0/0/0 是否真的接在物理 GE0/0/0 上,避免下发配置时把 IP 配到错误接口

  • 拓扑图纠错:发现接口错位后,用 ensp_gather_diagnostic_context 收集上下文,让 LLM 给出修改建议(更新 .topo 或重新接线)

  • 实验前环境检查:学生实验前用本工具确认 eNSP GUI 接的线与设计一致

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topo_pathYes
lldp_resultsYes
device_aliasesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and it does most of it: it documents the classification logic (matched/topo_only/lldp_only/mismatched), that input is parsed from an absolute path, that both XML and ZIP are auto-detected, and that output is JSON + Markdown. It never explicitly states the operation is read-only / has no device side effects, which is the one remaining ambiguity.

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

Conciseness4/5

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

Well front-loaded with the purpose in the first line, then workflow, edge categories, parameters, and scenarios. The bulleted edge-category breakdown is informative but slightly verbose; a few lines could be tightened without loss.

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

Completeness5/5

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

For a three-parameter analysis tool with an output schema already present, the description covers input handling, the comparison algorithm, output format, sibling routing, and follow-up workflows. 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.

Parameters5/5

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

Schema coverage is 0%, so the description must compensate and does — it explains topo_path is an absolute .topo path, lldp_results is a list of ensp_verify_lldp_neighbors returns (recommending the scan field but tolerating the whole object), and device_aliases maps LLDP system-name to .topo names with a concrete example.

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

Purpose5/5

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

The description states a precise verb+resource — cross-validating .topo parse results against LLDP neighbors — and explicitly contrasts itself with siblings (ensp_parse_topology only reads the file; ensp_verify_lldp_neighbors reflects physical reality). An agent can pick this tool without opening any schema.

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

Usage Guidelines5/5

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

It names concrete when-to-use scenarios (pre-config interface validation, topology correction, pre-lab environment check) and points to the follow-up tool (ensp_gather_diagnostic_context) once mismatches are found. The condition selecting it over the two sibling reads is stated outright.

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