关于 Eclipse Constellation MCP
Eclipse Constellation MCP 是用于通过策略检查和可审计回执账本管理已声明 VM 目标的只读 MCP 服务。它面向管理 Agent 机器访问权限的团队;v0.1 仅评估生命周期请求,不执行操作。
主要功能
- 01列出已声明的 VM 目标
- 02按策略评估生命周期操作
- 03运行固定模板的只读探测
- 04保存集群快照
- 05验证哈希链回执
适用场景
- 01检查 VM 操作是否符合配额和允许列表
- 02在不使用自由命令的情况下检查主机
- 03记录集群状态和策略决策
- 04审计探测及拒绝的评估
MCP 相关
通过本地 stdio 向 MCP 客户端提供五种工具:目标列表、策略评估、固定模板探测、集群快照和回执查询。它只评估生命周期操作,不会执行操作。
配置
本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。
工具
5收录的工具列表 · 更新于 2 天前
此工具无需参数。
详细介绍
Eclipse Constellation MCP
由 Cyan Eclipse Technologies 提供支持 — https://cetech.ai
Eclipse Constellation — 面向 Agent 的受治理、厂商中立 VM 机群层:一套策略、一份收据账本,底层支持各种云和虚拟机监控程序。
为什么要构建它
如今,各种云和虚拟机监控程序都提供了自己的 Agent 接口,而且每种都只管理自己的资源。它们都没有提供更上一层的能力:谁有权对机器执行什么操作、依据谁的授权、受哪些限制——以及事后用于证明这一切的收据。Constellation 就是这一层。它将 Agent Wallet 模式从资金转用于机器:策略由人编写,在任何操作执行前进行检查,并将每项决策记入账本。
状态——如实说明
v0.1.0,规范阶段 C0+(机群状态 + 策略评估)。仅观测:此版本完全不包含任何变更代码路径。 此文件中的任何内容都无法启动、停止、调整大小、创建快照或销毁机器——生命周期操作仅作为策略评估存在,返回带有原因的 ALLOW/DENY。使用本地 stdio 传输,仅依赖 Python 标准库。唯一探测的目标是此主机,且仅通过其声明的通道进行。不声称已通过认证——基准测试待进行。
根据规范和此版本的安全说明,v0.1 中明确不包含以下内容:
- 不包含执行适配器。 ALLOW 是策略判定,不是操作。执行功能将在 C1+ 阶段加入,并由所有者把关。
- 不包含 Tier-3 ALLOW。 销毁、网络变更和快照删除每次都需要明确的人工确认;v0.1 尚未接入审批通道,因此此处的 Tier-3 评估始终返回 DENY,并说明原因。
- Eclipse Connect droplet 不是已声明目标。 其迁移(规范 §6.4:声明 → 读取 → 快照规范 → 受控变更)由所有者把关;v0.1 仅声明此 VM。
工具(5 个)
| 工具 | 功能 |
|---|---|
target_list | 仅列出已声明的目标:名称、类型、地址、声明的通道、所有者 Agent、desk、声明的资源。未声明的目标对所有工具都不可见。 |
policy_evaluate | 根据策略评估生命周期操作——配额(拒绝时显示计算过程)、镜像和网络允许列表、TTL 和用途规范、变更前创建快照的前置条件、Tier-3 审批把关。返回 ALLOW/DENY、原因和逐项检查结果。**每次评估都会生成收据,包括 DENY。**仅进行评估,不执行操作。 |
probe_target | 通过目标声明的通道,对已声明的目标进行只读探测。探测使用按名称选择的固定命令模板(identity、uptime、disk、memory、services)。不接受任意命令参数——这是 v0.1 的硬性规定,并在工具中强制执行。 |
fleet_snapshot | 探测每个已声明的目标,并存储带有收据的机群快照,其中包含各目标的状态、探测结果和时效性。 |
receipt_list | 列出账本收据(包括评估结果、含 DENY,探测和快照),并验证仅追加哈希链。 |
注册表原则
目标必须显式声明,绝不自动发现或临时创建:targets.json 是机群的设备注册表。每个目标都要声明类型、地址、通道(此主机使用 local——它未运行 sshd,且此版本不会启动 sshd;未来声明的远程目标使用 ssh,通过系统 ssh 客户端以批处理模式连接)、所有者 Agent、desk 和声明的资源。未声明通道的目标仅作为资产清单;此层绝不会自行指定通道。
随附的 v0.1 注册表:一个目标 self-vm——此 VM(声明为 2 vCPU / 8 GB)。targets.json 中声明的资源数值和 policy.json 中的镜像哈希都属于声明的元数据:镜像条目是已命名的注册表槽位,待 C1 阶段注册首批允许列表中的镜像时,才会填入实际哈希。
策略核心(spec §4,评估时执行)
- 配额是上限。 每个桌面和整个集群的 vCPU、RAM、磁盘及 VM 数量上限。任何会超出上限的创建操作都会被拒绝,原因字符串中会列出具体计算过程。
- 镜像和网络允许列表。 创建操作只能从已注册的镜像启动(名称,以及提供时的哈希);目标只能加入已声明的网络。新增网络属于策略变更,而不是运行时标志。
- 变更前创建快照是强制机制。
resize、image_change、exec_push、rollout和destroy都要求同一目标有一份新的快照收据。没有快照收据,就不能变更——这是强制检查,不是建议。 - 默认具有临时性。 创建操作必须提供用途标签,并设置不超过策略上限的 TTL(默认 24h,上限 168h)。永久保留需要人工授权。
- 身份必须绑定。 每次评估都必须注明操作者(Agent + 桌面)。匿名评估会被拒绝。
- 收据就是产品。 只追加、哈希链式关联、以 GENESIS 为锚点——评估、探测和快照都会写入同一账本(
data/state.json,可通过环境变量覆盖)。
快照收据绑定(v0.1 语义,直白说明): 在执行适配器上线之前,符合条件的快照收据是针对同一目标执行 snapshot_create 操作并获得 ALLOW 的评估收据,且必须在 policy.snapshot_fresh_seconds(24h)内保持有效。C1 适配器会记录相同形式的执行收据;前置条件检查不会改变。
运行
python3 server.py # MCP over stdio, stdlib only, no dependencies
python3 smoke.py # end-to-end smoke over real stdio (temp state)
python3 -m unittest discover tests # test suite
环境变量覆盖项:ECLIPSE_CONSTELLATION_STATE、ECLIPSE_CONSTELLATION_TARGETS、ECLIPSE_CONSTELLATION_POLICY。
路线图(spec §8)
C1 — 在首个已声明的适配器上,在策略约束下执行生命周期操作(由所有者把关;迁移 droplet 是所有者自己的决策)。C2 — 在已声明的通道上构建 exec 和控制台层。C3 — 在同一策略核心后接入第二种底层平台。届时,供应商中立这一主张将变得可测试,也就可以公开宣称了。
Cyan Eclipse Technologies 的产品。“Powered by Cyan Eclipse Technologies”署名将随产品一同保留。
评论
一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。