MCP server for per-user, impersonated filesystem access on the AF platform
Wellknown found it in public sources; nobody has proven control of it yet. Claiming takes one click if the repository is under your GitHub account, or a small file on your domain otherwise. Verified owners get the badge, 15-minute checks, status alerts, edits that outrank crawled data, and a ranking boost.
Agents can do it too: POST https://wellknown.network/api/v1/claims with {"agent":"af-filesystem-mcp","method":"well_known_file"} — machine-readable steps at claim.json, guide at /docs/claim.
Everything here was measured by our prober or read from a registry. Nothing is self-reported.
Attributed to the source that supplied each field. Treated as claims, not facts.
# af-filesystem-mcp v0.1.3 <!-- --8<-- [start:intro] --> An MCP server that gives an AF (Analysis Facility) user browse/read access to their own files on the AF's shared NFS home (`/home/<unixname>`) and Ceph data area (`/data/<unixname>`) — nothing more. Designed to sit behind af-mcp-platform's credential broker so an LLM session can look at a user's own analysis outputs, condor logs, and scratch files without a human copying paths around. <!-- --8<-- [end:intro] --> <!-- --8<-- [start:what-it-does] --> ## What it does - **List** a directory (`fs_list`) - **Read** a file, by byte range or line range, including head/tail (`fs_read`) - **Stat** a path — size, mtime, type, permissions (`fs_stat`) - **Grep** for a pattern across files under a directory, capped in files scanned and matches returned (`fs_grep`) That is the entire v1 tool surface. There is deliberately no write tool, no delete, no chmod, no arbitrary command execution, and no full-tree walk (directory-size, duplicate-finder). See `CLAUDE.md` for the design rationale and phase-2 (write) plan. <!-- --8<-- [end:what-it-does] --> <!-- --8<-- [start:security-model] --> ## Security model Every filesystem operation for user _alice_ runs in a short-lived helper subprocess **impersonating alice's real uid/gid** — the server process itself (running as root, holding only `CAP_SETUID`/`CAP_SETGID`) never reads or writes a byte of user data directly. This means the kernel (and, for the NFS-mounted homes, the NFS server) enforces every permission check against the real identity: even a bug in this server's own path-pinning logic can only let alice reach what alice's real uid could already reach. See `CLAUDE.md` § "Security model" and `src/af_filesystem_mcp/paths.py` for the full design rationale, and [maniaclab/af-mcp-platform#188](https://github.com/maniaclab/af-mcp-platform/issues/188) for the workplan and the (rejected) alternatives this design was chosen over. <!-- --8<-- [end:security-model] --> <!…
Mapped onto the structured taxonomy from declared text and observed tool names. Confidence shown for derived entries.
Every source is kept verbatim. Field changes are logged as events.