AGTS MCP Server

AGTS MCP 服务

主权 MCP 网关——为自主 Agent 提供受治理的工具调用

Model Context Protocol 服务，可将工具调用转化为经过密码学授权、可验证的操作。提供 6 个层级的 115+ 个受治理工具，采用 Ed25519 + SLH-DSA 混合签名并锚定到 Merkle 树。旨在支持 EU AI Act、GDPR、SOC 2、ISO 27001、DORA、NIS2 和 FINRA 合规要求。

---

服务 URL

https://mcp.obligationsign.com/mcp

传输方式	URL	状态
Streamable HTTP（主要）	https://mcp.obligationsign.com/mcp	已启用
SSE（已弃用）	https://mcp.obligationsign.com/mcp/sse	已弃用

身份验证

该网关需要通过 ObligationSign 平台签发的 Bearer 令牌。所有请求都必须包含 Authorization 标头。

如需获取令牌，请在 obligationsign.com/start/ 注册。

快速开始

Claude Desktop / Cursor / Windsurf

将以下内容添加到 MCP 配置中：

{
  "mcpServers": {
    "agts": {
      "url": "https://mcp.obligationsign.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN"
      }
    }
  }
}

编程方式（通过 HTTP 使用 JSON-RPC）

curl -X POST https://mcp.obligationsign.com/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list",
    "params": {}
  }'

---

什么是 AGTS？

AGTS（Autonomous Governance Transparency Standard，自主治理透明度标准）是一种以透明度为支撑的治理协议，可将经验证的机器决策转化为仅追加的密码学记录，并由见证者和监控者网络独立验证。

decision → record → immutable history → verifiable truth

每次工具调用在执行前都必须通过五道防火墙关卡（统计、因果、回归、证据、与人类兼容的解释）。获准执行的操作会锚定到仅追加的透明度日志中的 Merkle 树，并使用混合后量子密码学进行签名。

---

密码学与验证者法定人数

此服务生成的每个治理信封都使用混合后量子签名签名：并行使用经典 Ed25519 和 SLH-DSA-SHAKE-128f。如今可使用仅支持 Ed25519 的工具验证签名；借助 SLH-DSA，即使面对未来的量子攻击者，签名仍能抵抗伪造。此外，Sovereign Mail 还使用 ML-KEM-512 进行加密密钥交换，信任对等方的仪式则使用 ML-DSA-44。

受治理工具调用的准入决策需要独立的 4 名验证者中至少 3 名组成法定人数，并满足约束 regulator_count ≥ 1 和 auditor_count ≥ 1。验证者作为独立的 Cloudflare Workers（agts-validator-{a,b,c,d}）部署，各自拥有不同的 ECDSA P-256 密钥对；每个验证者都会独立重新评估证明包，并签署 AGTS_VOTE_V1 证书。随后，法定人数证书会与治理信封一同锚定到 Merkle 透明度日志中，因此任何外部方都可以重建四份已签名投票，并验证法定人数是否按规定达成。

工具目录（115+ 个工具）

第 1 层——基础设施

VPN 与网络

工具	描述
create_tunnel	建立经过证明的 VPN 隧道（WireGuard/IPSec/TLS）
tunnel_status	监控运行时间、传输字节数和证明状态
disconnect_tunnel	终止会话并记录事件
dns_query	通过 Sovereign 解析器进行安全 DNS 解析

监控

工具	描述
system_health	检查所有网格工作进程的状态和延迟
check_alerts	获取监控警报时间线
subscribe_alerts	订阅 Webhook 实时警报
check_equivocations	获取相互冲突的 Signed Tree Head 证明
gossip_status	查看 Gossip 协议和监控者身份的当前状态

第 2 层——身份与通信

Sovereign Mail

工具	描述
send_sovereign_mail	发送加密消息（内部）或明文消息（外部）
list_inbox	列出收件箱中的消息元数据
read_message	按 ID 获取完整消息内容
lookup_recipient_keys	获取公钥（ECDH P-384 / ML-KEM-512）

Sovereign Drive

工具	描述
upload_file	客户端加密上传，并锚定完整性
list_files	列出文件元数据、大小和共享状态
download_file	获取密文，以便在客户端解密
share_file	使用 ECDH 密钥封装来共享文件
delete_file	删除文件，并在日志中创建一个死亡叶

OpenClaw（Agent 身份）

工具	描述
register_claw	创建加密 Claw Passport 和身份密钥
scan_skill	通过五道防火墙关卡扫描 Agent 技能
claw_status	返回信任评分、治理历史和配额
export_passport	安全导出身份信封
govern_skill_exec	技能执行的高级关卡
report_skill_execution	将技能结果关联至授权
verify_skill_proof	对技能扫描进行加密验证

Peer Trust（后量子）

工具	描述
authenticate_peer	混合 PQC（ML-DSA-44）+ 经典（ECDSA）身份验证流程
verify_agent_identity	通过密钥注册表检查指纹和吊销状态
exchange_credentials	使用混合 ECDH + ML-KEM-512 进行安全传输
peer_trust_network	列出已知对等方及其相互信任状态

第 3 层 — 治理

工具	描述
submit_governance	执行前关卡评估（ADMIT/QUARANTINE/REFUSE）
verify_commitment	使用 Merkle 证明验证透明日志中的承诺
report_execution	记录已授权操作的结果
update_policy	更新防火墙参数
list_policies	列出活跃的治理阈值和历史记录
governance_report	汇总决策报告
governance_stats	各关卡的通过/失败统计和 HCE 分布
gate_analysis	详细拆解特定评估决策

第 4 层 — 记忆

工具	描述
memory_store	存储分层键值条目
memory_recall	按路径检索特定条目
memory_list	按前缀列出记忆
memory_search	使用向量嵌入进行语义相似度搜索
cross_session_recall	跨历史会话进行语义搜索
memory_context	基于模式生成上下文摘要
consolidate_memory	比较并精简冗余条目
memory_gc	清理过期条目
set_memory_ttl	配置条目的自动过期时间
memory_delete	删除特定记忆路径

第 5 层 — 计费

工具	描述
provision_resource	为 Agent 创建计费项目
manage_spending	冻结/解冻支出
check_project_billing	详细的用量和费用明细
verify_provision	检查计费项目关联关系
set_budget_alert	配置支出阈值
check_budget	实时跟踪支出与上限

第 6 层 — 编排

工具	描述
spawn_sub_agent	启动一个隔离的异步子 Agent
sub_agent_status	轮询子 Agent 执行状态
sub_agent_result	获取子 Agent 结果
chain_delegation	递归委派，并设置预算递减和深度限制
create_template	定义可复用的多步骤工作流
apply_template	将模板实例化为运行中的任务
list_sub_agents	列出活跃的子 Agent
list_templates	列出可用的工作流模板
cancel_sub_agent	终止正在运行的子 Agent
merge_sub_results	汇总并行子 Agent 的结果
delegation_tree	重建委派链的完整谱系

---

REST API

除 MCP 外，网关还提供 REST 端点：

端点	描述
GET /api/v1/health	上游服务健康检查
GET /api/v1/audit	审计日志查询
GET /api/v1/assets	资产管理
GET /verify?commitment={hash}	使用 Merkle 证明验证承诺

---

架构

MCP 服务是访问 AGTS 协议的一种方式。完整的清算所规范另行发布。

Agent ─── MCP Gateway ─── Five-Gate Firewall ─── Transparency Log
               │                                        │
               ├── Mail Worker (E2EE)                   ├── Merkle Tree
               ├── Drive Worker (Encrypted Storage)     ├── Signed Tree Heads
               ├── OpenClaw (Identity)                  └── Gossip Protocol
               ├── Tunnel Worker (VPN)
               ├── Monitor Worker (Health)
               └── Protocol Worker (Governance)

---

此服务的不同之处

生态系统中的大多数 MCP 服务（约 83%）都是轻量级 API 封装——将单个连接器作为一两个工具公开，通过 stdio 在本地运行，且没有身份验证或验证机制。GitHub、Slack 和 AWS 等厂商提供的生产级服务（约 2%）构建完善，但架构简单：它们将 tools/call 转换为对自身服务的 API 请求。

此服务则处于不同层级。它不是外部 API 的封装，而是实现了完整的治理协议，其中：

• 每项操作在获得执行授权之前，都必须通过五道评估关卡
• 获准的操作会经过加密签名（混合 Ed25519 + SLH-DSA），并锚定到 Merkle 树的仅追加透明日志中
• 执行结果会追溯至其授权，从而形成闭环治理流程
• 独立监控器通过gossip 协议验证日志一致性，检测抵赖或篡改
• 身份验证采用后量子密码学（ML-DSA-44、ML-KEM-512），以实现前向安全

因此，每次工具调用都会生成可独立验证的加密证据，证明哪些操作获得了授权、哪些操作已执行，以及执行结果是否符合授权要求——这是受监管行业（金融服务、医疗保健、法律、关键基础设施）所要求的审计跟踪。

监管合规准备

网关的架构旨在支持多个监管框架的合规要求。下表将具体要求与相应的 AGTS 功能相对应。

EU AI Act

要求	AGTS 实现
第 9 条——风险管理	五道关卡防火墙在执行前评估每项操作；QUARANTINE 决策支持人工干预
第 12 条——记录保存	采用带签名治理信封的仅追加 Merkle 透明日志；自动记录每项授权和执行事件
第 13 条——透明度	每项承诺都可通过加密包含证明独立验证；治理决策可通过 HCE（Human-Compatible Explanation，人类兼容解释）关卡进行说明
第 14 条——人工监督	关卡阈值可配置；QUARANTINE/REFUSE 决策会停止执行；策略更新本身也受治理并记录在日志中

SOC 2

信任原则	AGTS 实现
安全性	混合 Ed25519 + SLH-DSA 签名；后量子密钥交换（ML-KEM-512）；通过电子邮件绑定进行 Cloudflare Access 身份验证；按工具进行速率限制
可用性	多工作器网格架构，配有独立健康监控；gossip 协议可检测节点故障；system_health 探测所有上游服务
处理完整性	五道关卡防火墙在执行前验证每项操作；执行结果会追溯至授权；检测偏离预期结果的差异
保密性	端到端加密邮件（ECDH P-384 密钥封装）；客户端加密的云盘存储；用于网络隔离的经证明 VPN 隧道
隐私	不以明文存储消息内容；通过 Claw Passport 实现加密身份验证；支持撤销的密钥注册表

ISO 27001

控制领域	AGTS 实施
A.8 — 资产管理	通过加密哈希追踪每个文件、消息和身份密钥；死亡记录会留下资产删除记录
A.9 — 访问控制	持有者令牌身份验证；Cloudflare Access 邮箱绑定；通过 Claw Passport 和信任评分为每个 Agent 分配身份
A.10 — 密码学	混合使用经典签名与后量子签名（Ed25519 + SLH-DSA）；PQC 密钥交换（ML-KEM-512）；邮件加密使用 ECDH P-384
A.12 — 运营安全	不可变透明日志；独立监控工作进程通过八卦协议验证日志一致性；检测抵赖
A.16 — 事件管理	告警订阅系统；抵赖检查可检测相互冲突的已签名树头；治理偏差记录用于追踪偏离情况
A.18 — 合规	所有治理决策、策略变更和执行结果均通过加密方式锚定；审计轨迹可独立验证

DORA（数字运营韧性法案）

要求	AGTS 实施
第 6 条 — ICT 风险管理	五道关卡防火墙会在执行前进行风险评估；各关卡阈值可按策略配置；治理统计数据提供各关卡的通过／失败分析
第 9 条 — 检测	监控工作进程持续探测服务健康状况；八卦协议可检测不一致；告警订阅支持实时事件通知
第 10 条 — 响应与恢复	QUARANTINE 决策会暂停高风险操作；manage_spending 可冻结 Agent 预算；执行追踪会将故障关联到相应授权
第 11 条 — 测试	每项治理决策都可通过 Merkle 包含性证明独立验证；verify_commitment 支持随时进行第三方审计
第 15 条 — 第三方风险	子 Agent 委派会强制实施预算递减和深度限制；chain_delegation 追踪递归委派链路；delegation_tree 重建完整来源链

GDPR

要求	AGTS 实施
第 5(1)(a) 条 — 合法、公平、透明	每项 Agent 操作都通过五道关卡防火墙预先授权；治理决策包含 HCE（人类可理解的解释），以便说明决策理由
第 5(1)(e) 条 — 存储限制	memory_gc 会清理过期条目；set_memory_ttl 强制自动过期；delete_file 会创建加密死亡叶，证明文件已删除
第 5(1)(f) 条 — 完整性与保密性	邮件和云盘存储采用端到端加密；混合后量子密码学；仅追加透明日志确保完整性
第 17 条 — 被遗忘权	memory_delete 会删除指定的记忆路径；delete_file 结合死亡叶可提供可验证的删除证明
第 25 条 — 通过设计实现数据保护	通过 Claw Passport 实现加密身份（无需 PII）；存储文件采用客户端加密；密钥注册表支持撤销
第 30 条 — 处理活动记录	Merkle 透明日志会记录每项授权、执行和策略变更，并附上时间戳和加密签名

NIS2

要求	AGTS 实施
第 21 条 — 网络安全风险管理	治理防火墙、加密签名、透明日志和后量子密钥交换共同构成纵深防御架构
第 23 条 — 事件报告	带有 Webhook 订阅的告警系统；抵赖检测；治理偏差记录提供取证证据链
第 21(2)(d) 条 — 供应链安全	通过预算控制和深度限制编排子 Agent；委派树可追踪跨 Agent 边界的完整来源链

FINRA

要求	AGTS 实现
规则 3110 — 监督	五道关卡防火墙会在每项 Agent 操作执行前进行监督；QUARANTINE/REFUSE 决策可防止未经授权的交易
规则 3120 — 监督控制系统	治理统计数据和关卡分析可提供监督分析；策略阈值可配置，且其自身也受治理
规则 4511 — 账簿和记录	仅追加的 Merkle 透明日志，采用 Ed25519 + SLH-DSA 对治理信封进行签名；每项授权和执行都会被永久记录
规则 3310 — 反洗钱合规	submit_governance 会在授权任何金融操作前评估包括价值、接收方和意图在内的证据；偏差检测会标记异常
规则 2210 — 通信	send_sovereign_mail 通过治理预授权，确保所有 Agent 通信在发送前都经过审核并记录

市场上最接近的可比对象并非另一个 MCP 服务，而是受监管企业为控制其 AI Agent 在生产环境中的行为而自行构建的系统。

---

规范

AGTS Clearinghouse 规范的规范性文本可在以下位置查阅：

github.com/obligationsign/agts-clearinghouse

---

链接

• 落地页：obligationsign.com/mcp/
• 平台：obligationsign.com
• 规范：github.com/obligationsign/agts-clearinghouse
• MCP 注册表：registry.modelcontextprotocol.io

---

许可证

本文档仅供参考和集成之用。MCP 服务由 ObligationSign 运营。协议条款请参阅 AGTS Clearinghouse 规范。