I've been using Claude Code (CLI) heavily, but I hit a major friction point: When Claude generates artifacts locally (like a specific SQLite dump, build logs, or a patch), it has no easy way to "hand" them to a coworker.
I didn't want to upload sensitive local files to a third-party cloud (S3/Drive) just to send a temporary file to a teammate sitting virtually next to me.
So, I built an MCP server (ffl-mcp) that gives Claude the capability to share files directly via P2P.
The Workflow:
1. I ask Claude: "Zip the logs and send them to Bob."
2. Claude uses the tool to generate a one-time P2P link.
3. My coworker clicks the link to download immediately (streaming transfer, E2EE).
Under the hood:
It wraps ffl [0], a CLI tool I built for NAT traversal (WebRTC, relay if failed). (I packaged the core tool as an "Actually Portable Executable" so it runs as a single binary across platforms without Python environment headaches).
I've been using Claude Code (CLI) heavily, but I hit a major friction point: When Claude generates artifacts locally (like a specific SQLite dump, build logs, or a patch), it has no easy way to "hand" them to a coworker.
I didn't want to upload sensitive local files to a third-party cloud (S3/Drive) just to send a temporary file to a teammate sitting virtually next to me.
So, I built an MCP server (ffl-mcp) that gives Claude the capability to share files directly via P2P.
The Workflow:
1. I ask Claude: "Zip the logs and send them to Bob."
2. Claude uses the tool to generate a one-time P2P link.
3. My coworker clicks the link to download immediately (streaming transfer, E2EE).
Under the hood:
It wraps ffl [0], a CLI tool I built for NAT traversal (WebRTC, relay if failed). (I packaged the core tool as an "Actually Portable Executable" so it runs as a single binary across platforms without Python environment headaches).
It's open source and you can try it with uvx: https://github.com/nuwainfo/ffl-mcp
[0] The core ffl tool: https://github.com/nuwainfo/ffl