“AFS 支持 MCP”有哪两个方向？

向 MCP 客户端暴露 AFS，与把 MCP 服务挂入 AFS，是两种适配。

MCP（Model Context Protocol）是 AI 应用连接外部能力的协议。工具用于执行操作，资源用于读取内容，prompt 是可带参数的提示模板。这里讨论 AFS 在连接的哪一侧。

先画出箭头

方向	谁在使用谁	主要结果
AFS 作为 MCP server	MCP 客户端调用 AFS 操作	用路径访问 AFS 环境
MCP 作为 AFS provider	AFS 调用外部 MCP server	将工具、prompt 和资源接入命名空间

第二种方向由 AFSMCP 这样的适配器实现。其说明把外部工具放在 /tools/<name>，prompt 放在 /prompts/<name>，并生成用于发现的 WORLD.md；这些是 provider 内部的入口，调用者还要加上实际挂载位置。

可以组合，但语义不能省略

外部工具可能产生副作用，资源可能使用自己的标识与认证，prompt 可能需要参数。适配器必须保留或明确转换这些约定，不能只把所有返回值都当普通文本。

一个系统可以同时具有两个方向，但不应因此无意建立递归调用或扩大权限。评估时分别检查：外部服务被暴露了什么，哪个调用者可使用，以及失败如何穿过适配边界。

把检索工具挂到一个具体位置

AFSMCP 是把外部 MCP 服务转换成 AFS provider 的适配器。假设外部服务提供 search 工具，适配器内部入口是 /tools/search。把这个 provider 挂在 /services/library 后，AFS 调用者看到的完整入口就是 /services/library/tools/search。

调用者先发现这个挂载，读取该位置的说明或 WORLD.md，再查看工具输入，最后才执行工具入口。WORLD.md 是供人或 agent 读取的发现说明，帮助了解适配后的世界；它不是自动执行脚本。反过来，MCP 客户端使用 AFS server 时，调用的是服务端暴露的 AFS 工具，再把资源路径作为参数传入。

两个方向的教学记录（返回值是示意）：

AFS 调用者 → exec /services/library/tools/search {query:"AFS"}
外部 MCP 工具 → 返回匹配的文档列表

MCP 客户端 → afs_read {path:"/work/report"}
AFS server → 返回报告资源的数据