What are the two directions of MCP integration?

MCP (Model Context Protocol) connects AI applications to external capabilities. Tools perform operations, resources expose readable content, and prompts supply parameterized guidance templates. The distinction here is which side of the connection AFS occupies.

Draw the arrows first

AFSMCP implements the second adapter direction. Its documented provider-local entries include /tools/<name>, /prompts/<name> and a generated WORLD.md for discovery. The caller also needs the actual mount prefix.

Composition still needs semantics

External tools may have side effects, resources may have their own identifiers and authentication, and prompts may require arguments. The adapter must preserve or explicitly translate those contracts rather than flatten every result into ordinary text.

A system may use both directions. That should not accidentally create recursive calls or broaden authority. Check what is exposed, which callers can use it and how errors cross the adapter boundary.

Mount a search tool at a concrete location

AFSMCP adapts an external MCP service into an AFS provider. Suppose the service offers a search tool at the provider-relative entry /tools/search. Mounted at /services/library, its full AFS address becomes /services/library/tools/search.

A caller discovers the mount, reads its explanation or WORLD.md, checks the tool inputs and then executes the tool entry. WORLD.md is discovery guidance for a person or agent, not an executable script. In the opposite direction, an MCP client calls tools exposed by the AFS server and supplies the resource path as an argument.

Illustrative traces, with schematic responses:

AFS caller → exec /services/library/tools/search {query:"AFS"}
External MCP tool → matching documents

MCP client → afs_read {path:"/work/report"}
AFS server → report resource data

The first imports an external capability into AFS. The second exposes an existing AFS resource to an MCP client.