Let AI agents work on huge datasets without transferring them
KeibiDrop connects two machines directly and gives both sides the same folder, encrypted end to end, with no cloud storage in between. kdmcp lets AI agents drive it as an MCP server: the remote folder mounts as a normal path, the agent reads files where they sit, and only the bytes it reads cross the wire. In a measured run, reading 1 MB out of a 256 MB file moved 16.8 MB instead of the whole file, and a 2,184-file dataset was listed 0.53 seconds after pairing. Setup is one config entry, and pairing needs a code from each side, so a single leaked code connects nobody.
Your agent needs a dataset that lives on another machine. The weights are on the GPU box, the corpus is on the workstation, the build is on the laptop. Today the agent either downloads all of it before the first useful step, or you stand up a storage bucket and teach it to use one. Either way the agent waits, and for 50 GB it waits a long time.
KEIBIDROP is an open-source tool that connects two machines directly and shows a folder from one as a normal folder on the other. The agent reads files where they sit, and only the bytes it reads travel. No account, no cloud storage in between, and the connection is encrypted end to end.
The agent starts working in the first second
The full file listing arrives before any content moves. In the run below, a folder of 2,184 files across six levels was listed on the far machine 0.53 seconds after the two peers connected. From that moment the agent can walk the tree, pick the files that matter, and read exactly those. It is not blocked behind a transfer, because there is no transfer step.
One take, 12 seconds. The left agent offers a dataset. The right agent lists it and reads a file out of it. The clock along the bottom runs through the whole thing.
Only the bytes it reads cross the wire
Content moves in 16 MiB blocks, on demand. We had one agent read 1 MB from the middle of a 256 MB file on the other machine: 16.8 MB crossed the wire, which is the block around the read plus its integrity hashes, and 6.25% of the file. A copy would have moved all 256 MB first. The bigger the files, the better that fraction gets, because a small read costs about one block whatever the file size.
This is the difference for dataset work. Sampling a corpus, checking a schema, reading the header of every shard: these touch a small part of the data, and now they cost a small part of the data.
Keep git and the rest of your tools
The remote folder mounts as a real path, so anything that reads files works on it unchanged. Your agent can git clone a repository straight off the other machine, grep the logs, or point a Python script at the data. We tested more than 25 programs across the mount, including git, cargo, ffmpeg, Python, Node.js and SQLite, and integrity held in both directions.
Nothing gets replaced. You keep your version control, your build system and your scripts, and the mount brings the remote files to them. There is no SDK to teach the model either, because agents already know how to use a filesystem.
Setup is one config entry
kdmcp is an MCP server, the plug that Claude, Cursor and most agent tools already accept. It exposes 17 tools over stdio: pair, list, read, pull, check progress, disconnect.
claude mcp add-json keibidrop '{
"command": "/usr/local/bin/kdmcp",
"env": {
"KD_SHARE_ROOT": "/home/me/KeibiDrop/Share",
"KD_SAVE_PATH": "/home/me/KeibiDrop/Received",
"KD_MOUNT_PATH": "/home/me/KeibiDrop/Mount"
}
}'Any client that reads an mcpServers object takes the same three lines, and kdmcp install prints the snippet with the right paths for the machine it runs on. Nothing has to be created first. The server makes its directories, generates its identity and starts its engine when the client launches it.
Measured
| Run | Result |
|---|---|
| Folder of 2,184 files, offered at startup | Listed on the far machine 0.53 s after the session came up |
Same folder through kd_send_file, one call per file | 61 s, so name big folders at startup instead |
| 1 MB read from the middle of a 256 MB file | 16.8 MB on the wire, 6.25% of the file, content matched |
| 40 MB download cut at 8 MB, then resumed | Finished, checksums matched on both sides |
| Pairing, both sides through the relay | 3.5 to 4.3 s |
These runs put both peers on one Mac and sent the session through our relay in Timisoara rather than a direct link, so the wall-clock times include real round trips on one shared uplink. The byte counts are the numbers to take from this rig. Wall-clock speed belongs to the link you run it on.
A pull outlives the tool-call timeout
When the agent does want a local copy, downloads are asynchronous. kd_pull_file returns a transfer id immediately and kd_transfer_status reports progress until it is done, so a tool call never blocks on a 50 GB transfer. An interrupted download resumes from where it stopped: we cut a 40 MB pull at 8 MB, reconnected, and it finished with a matching checksum on both sides.
One code connects nobody
Pairing is mutual. Each machine reads its own code and passes the other machine's code in, and neither side connects on one code alone. There is no trust on first use, so a leaked code by itself connects nothing. The two codes travel over whatever channel the people or the agents already share.
Sending has its own gate. The server refuses to send anything unless KD_SHARE_ROOT names a directory, and then it only sends paths inside that directory. Leave it unset on a machine that should only receive.
It is in main today
kdmcp is in the repository now and builds with make build-kdmcp. The next release will carry the binary. The mount needs a FUSE provider on the reading side: WinFsp on Windows, macFUSE on macOS, and on Linux libfuse3 is usually there already. Without one, the same tools work in copy mode, and kd_pull_file writes real files into KD_SAVE_PATH.
Install guide · Source code · The same mount, driven by hand