{"id":47244083,"title":"Show HN: Mcpfs – Mount MCP servers as FUSE filesystems","points":2,"user":"evoleinik","time":1772607620,"time_ago":"8 hours ago","type":"link","content":"

CLIs are programs. Files are data. When you run "stripe balance retrieve", you're executing a program to get data that already exists. That's the wrong abstraction.

I built mcpfs to treat API data as what it is — files:

  cat /mnt/mcpfs/stripe/balance.json | jq\n  cat /mnt/mcpfs/posthog/dashboards.json | jq '.[].name'\n  cat /mnt/mcpfs/linear/issues.json | jq '.[].title'\n

\nEvery service works the same way. No flags to remember — not "gh --json --jq", not "stripe --format json", not "kubectl -o json". Just cat | jq. Discovery is ls. You already know the entire interface.

You can compose native CLIs too — but you need to remember each one's JSON flags, and some services (PostHog, Linear, Notion) have no CLI at all. With mcpfs every service is the same syntax, so cross-service pipes just work:

  # Paying customers with no analytics activity\n  comm -23 \\\n    <(cat /mnt/mcpfs/stripe/customers.json | jq -r '.[].email' | sort) \\\n    <(cat /mnt/mcpfs/posthog/events.json | jq -r '.[].distinct_id' | sort)\n

\nFor writes, where good CLIs exist (gh, stripe, kubectl), use them. For services with no CLI — PostHog, Linear, Notion — mcpfs proxies their upstream MCP tools into a CLI:

  mcpfs-posthog create-feature-flag --key my-flag --active\n  mcpfs-linear create_issue --teamId abc --title "Fix login bug"\n

\nUnder the hood: each server is a Go binary (200–400 lines) that calls the service API and exposes data as MCP resources. mcpfs mounts them via FUSE. The MCP ecosystem has 18,000+ servers that all expose tools — mcpfs flips that: reads are resources (files), writes stay as tools (CLI).

  git clone <https://github.com/airshelf/mcpfs> && cd mcpfs && go build ./...\n

\n<https://github.com/airshelf/mcpfs>","url":"https://github.com/airshelf/mcpfs","domain":"github.com","comments":[],"comments_count":0}