Skip to main content
Glama
cheese-sansan

MCP_HCL

by cheese-sansan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

MCP_HCL

与 Agent 客户端无关的 HCL MCP Server，当前版本 0.5.0。本地主分支整合了已有分支历史和最新已验证的软件成果；完整 MCP-Packet-Tracer 62 工具/5 资源等价仍为 Incomplete。

接手读 HANDOFF.md，完整索引见 docs/README.md。当前发现面为 55 工具/6 资源；发现、软件合同、原生配置与真实流量分别记账，full_live_gate_passed=false。

能力与限制

  • 离线工程检查、阶段副本、编辑、严格规划与配置/操作清单生成，支持哈希绑定的导出和重载。

  • 原生配置服务包含 ACL/VLAN/NAT、接口调优、STP/端口安全与 NetStream；默认写入关闭，必须绑定实际设备、备份、范围回读和恢复入口。

  • 差异、健康、地址观察和安全审计保留未知值及模拟/原生来源；不把缺字段、阶段库存或保存文件解释为完整实时拓扑。

  • GUI 保护验证身份、当前账号目录、监听者及工程回执；不能证明厂商运行时环境或清理边界。

上游工具库存仍为 12 implemented / 47 planned / 3 unverified。原生完整设备/线缆库存、若干 IOS→Comware 行为映射、命名 exporter/monitor 与安全 Phone 关联等仍缺。

2026-10-11 具名报告记录一次单设备隔离生命周期和账号清理；候选独占 CLI 被后台 MultiCC 保护拒绝，配置与网络验收未完成。证据位置与后续门槛见 当前交接 和 测试指南。

Related MCP server: Vivado Agent MCP

安装与运行

需要 Python 3.11+；原生功能需要合法安装的 Windows HCL。使用当前工作区的独立环境：

python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e '.[dev]'
$env:MCP_HCL_PROJECT_ROOTS = 'C:\Users\YOUR_NAME\HCL\Projects'
$env:MCP_HCL_OUTPUT_ROOT = (Join-Path (Get-Location) 'work\staged')
$env:MCP_HCL_INSTALL_ROOT = 'D:\HCL'
$env:MCP_HCL_ALLOW_LIVE_WRITE = '0'
.\.venv\Scripts\python.exe -m mcp_hcl.server

stdio 服务等待协议输入；在 MCP 客户端配置相同解释器、工作区和环境。阶段工具仅写隔离输出副本。原生写入须按 统一测试计划 处理身份、资产和恢复前提。

开发与验证

.\.venv\Scripts\python.exe scripts\check_all.py

该入口运行 Ruff 和全部软件检查，强制真实写开关为 0，并为每轮保存独立回执。历史成功与失败不覆盖。开发规范和模块职责见 development.md。原始检查结果定位见 HANDOFF。

参数见 离线 API、严格合同 v2 和 Schema。日期化报告、重复交接与旧脚本快照已移出维护文档，保留 Git 历史和仓库外备份。

Available Tools

5 tools
hcl_capabilitiesC

Describe verified capabilities and the activation boundary.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

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, and it says nothing about side effects, permissions, or whether this is a safe read. The word 'verified' hints that some capabilities may be unverified, but that distinction is never explained.

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?

A single short sentence with the object stated up front and no filler. It is efficient, though the brevity comes at the cost of the detail that would make it actionable.

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

Completeness3/5

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

An output schema exists, so return values need not be described in prose, which relieves much of the burden. Still, with no annotations and abstract terminology, the definition leaves an agent unsure what 'activation boundary' refers to or when invoking this tool is the right move.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify on the input side.

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

Purpose3/5

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

The description has a verb ('Describe') and an object ('verified capabilities and the activation boundary'), so it is not a tautology. However, 'capabilities' and 'activation boundary' are abstract domain terms with no concrete indication of what is actually returned or what area of the API this covers, so an agent cannot confidently distinguish its scope from siblings like hcl_inspect_project.

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

Usage Guidelines2/5

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

There is no guidance on when to call this tool, when not to, or which sibling to prefer. The sibling names (hcl_list_projects, hcl_inspect_project, hcl_stage_add_device, hcl_stage_link) suggest an orchestration workflow where a capability-check step would matter, but the description does not connect itself to that flow.

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

hcl_inspect_projectB

Read devices and links from one saved HCL project without changing it.

NameRequiredDescriptionDefault
project_pathYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

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 does disclose the key behavioral trait that the operation does not modify the project, which is valuable, but it says nothing about auth requirements, error behavior, or scope limits. The read-only disclosure is the main value-add.

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

Conciseness5/5

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

A single front-loaded sentence with the verb first and zero wasted words. It is exactly as long as it needs to be for a simple one-parameter read tool.

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

Completeness4/5

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

An output schema exists, so return values need not be explained, and the tool is low-complexity with one parameter. The description covers purpose and the non-mutation behavior; the only real gap is the undocumented project_path semantics, which keeps it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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

There is one parameter (project_path) with 0% schema description coverage, so the description must compensate. It only implies that the path refers to a 'saved HCL project' but gives no format, path style, or resolution details, leaving the sole parameter effectively undocumented.

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

Purpose4/5

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

The description states a specific verb (read) and resource (devices and links from one saved HCL project), which is clearly distinguishable from hcl_list_projects and the stage_* write tools. It stops short of naming any sibling explicitly, so it does not reach the sibling-differentiation bar for a 5.

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

Usage Guidelines3/5

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

The phrase 'one saved HCL project' implies you use this to inspect a project that already exists, and 'without changing it' implies a safe read. However there is no explicit when-to-use vs alternatives (e.g., hcl_list_projects vs this), and no stated prerequisites, so usage is only implied.

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

hcl_list_projectsA

List HCL projects immediately under configured project roots.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior3/5

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 does disclose the non-recursive scope ("immediately under"), which is genuine behavioral information, but it says nothing about whether it requires configured roots to exist, how it behaves when none are set, or that it is a read-only operation.

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

Conciseness5/5

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

A single sentence with zero filler, front-loading the verb and resource and placing the scope qualifier where it is immediately readable.

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

Completeness4/5

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

For a zero-parameter read tool with an output schema present, the description is close to sufficient: return shape is covered by the schema and scope is stated. It could add one clause about the dependency on configured project roots or the follow-up inspection path.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

Zero parameters, so there is no parameter semantics to document. Baseline 4 applies; the description correctly implies the tool takes no filtering arguments.

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

Purpose4/5

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

Specific verb+resource ("List HCL projects") with a scoping qualifier ("immediately under configured project roots") that distinguishes it from a deep/recursive listing. It is distinguishable from hcl_inspect_project, which clearly targets a single project, though it never names that sibling explicitly.

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

Usage Guidelines2/5

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

No when-to-use or when-not-to-use guidance and no alternatives named. The agent must infer that this is the entry-point discovery tool and that hcl_inspect_project is the follow-up for detail; nothing in the description routes it.

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

hcl_stage_add_deviceC

Copy a project, add a device cloned from a known model, and optionally link it.

NameRequiredDescriptionDefault
xYes
yYes
new_nameYes
new_portNo
connect_toNo
stage_nameYes
project_pathYes
connect_to_portNo
template_deviceYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.4/5.0
Behavior2/5

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 the tool copies a project and adds a device, implying mutation, but does not cover irreversibility, permissions, side effects on existing project data, or how optional linking behaves. The output schema covers return values, but the mutation behavior remains opaque.

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?

The description is a single front-loaded sentence with no filler, moving directly through the action sequence. Its brevity is efficient, though arguably under-specified for the tool's complexity.

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

Completeness1/5

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

For a 9-parameter mutation tool with no annotations and zero schema descriptions, this one-sentence description is far too thin. It omits parameter semantics and usage context needed to invoke the tool correctly; the existence of an output schema does not compensate for the missing input guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

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

Schema description coverage is 0% for 9 parameters, so the description must compensate but does not. It names no parameters and explains none of the required inputs such as project_path, stage_name, new_name, x, or y; at best it vaguely hints at template_device via 'known model' and connect_to via 'link'.

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

Purpose4/5

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

The description states specific actions (copy a project, add a device cloned from a known model, optionally link it) and names the resources involved. It does not differentiate from siblings like hcl_stage_link or hcl_inspect_project, and the initial 'Copy a project' clause is slightly at odds with the tool name hcl_stage_add_device, but the overall purpose is clear.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives among the sibling tools. The description simply lists what the tool does, leaving the agent to infer context and prerequisites.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.1.0
    • First observedhcl_capabilities
    • First observedhcl_inspect_project
    • First observedhcl_list_projects
    • First observedhcl_stage_add_device
    • First observedhcl_stage_link
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.2/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: capabilities (meta), list_projects (enumerate), inspect_project (read), stage_add_device (add device), and stage_link (add link). The optional linking in stage_add_device could be confused with stage_link, but the descriptions clarify the primary actions and when to use each.

Naming Consistency4/5

All tools use the hcl_ prefix and snake_case, with operational tools following a verb_noun pattern (list_projects, inspect_project, stage_add_device, stage_link). hcl_capabilities is a noun phrase and breaks the verb-based convention, but only as a minor deviation.

Tool Count5/5

Five tools is well-scoped for a server focused on HCL project inspection and staged modifications. Each tool has a clear role, and there is no redundant or excessive tooling.

Completeness3/5

The surface covers listing, inspection, and additive staging (add device, add link), but lacks update, removal, or project creation/deletion operations. For a tool that manipulates HCL projects, these are notable gaps in lifecycle coverage.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers