HTTP 上的 AFS | ArcBlock

不会说 MCP 的客户端，可以在 /api/afs/rpc 上用普通 JSON-RPC 触达同一批 AFS 操作。数据面相同、访问档相同 —— 只有信封不同。

当调用方是一段脚本、一门没有 MCP 库的语言，或者一个能发 HTTP 请求但没有工具调用框架的模型时，用它。

调用

curl -s -X POST https://<host>/api/afs/rpc \
  -H 'Content-Type: application/json' \
  -d '{"type":"list","path":"/"}'

{
  "ok": true,
  "data": [
    {
      "id": "instance",
      "path": "/instance",
      "summary": "DID-scoped persistent storage with CID-based content deduplication…",
      "meta": { "childrenCount": -1 }
    }
  ]
}

请求在 type 里给出操作名，参数与之并列。响应包在 { "ok": …, "data": … } 里。

上面的请求没有发送任何凭证；匿名读在这里的行为与 /mcp 上完全一致。

读之前先看这个路径接受什么

stat 返回 provider 实际会接受什么，省掉一轮失败调用：

curl -s -X POST https://<host>/api/afs/rpc \
  -H 'Content-Type: application/json' \
  -d '{"type":"stat","path":"/packages"}'

{
  "ok": true,
  "data": {
    "id": "arcblock",
    "path": "/packages",
    "meta": {
      "kind": "did-space:directory",
      "capabilities": ["list", "read", "stat", "search", "write", "delete", "exec", "explain"],
      "accessMode": "readonly",
      "projection": { "base": "arcblock" }
    }
  }
}

capabilities 是 provider 实现了什么。accessMode 是这个调用方拿到什么。两者是分开的：provider 可以实现了 write，而该路径对你是 readonly。

把某个操作写进你的集成之前，先读 capabilities；provider 并不被要求实现全部操作。见 AFS。

与 MCP 工具的关系

	`/mcp`	`/api/afs/rpc`
信封	streamable HTTP 上的 MCP	JSON-RPC
操作	`afs_*` 工具，声明后另有内容工具	AFS 操作
匿名读	是	是
写入	需要凭证	需要凭证
发现方式	`tools/list`	对路径做 `stat` 和 `explain`

两个端点都列在该 host 的 API catalog 里，指向同一份服务描述。

客户端支持时优先用 /mcp：工具 schema 会告诉 agent 参数是什么，而 stat 不会。

写入

经此端点的写入与 /mcp 规则相同：需要凭证，且该路径必须已由 blocklet 向网络客户端发布。见访问分档。

完整的操作集合与参数形状属于 AFS 合同。