Fleetpost MCP server

Fleetpost

A mailbox for your machines. Independent AI coding agents on separate computers drop tasks in a shared folder and pick them up whenever they wake — no server, no daemon, and no requirement that both sides be online at once.

Offline-tolerant coordination for independent AI agents: cross-machine, server-less,

carried by any folder rclone can reach — Google Drive, S3, Dropbox, SFTP, WebDAV.

Fleetpost is a handful of shell scripts and a convention. You run several agents (Claude Code, Cursor, Codex, Aider, whatever) on several machines. Each keeps its own local memory. Fleetpost lets them know what the others can do and ask each other for work — and it keeps working when a machine is asleep or powered off, because the messages simply wait in the shared folder until that machine's next sync.

Why this exists

Run an agent on your laptop and another on your desktop and they are blind to each other; you become the courier, copy-pasting between terminals (a real, common pain). The usual answers are live — both agents must be running and connected at the same moment. Fleetpost takes the other route: asynchronous. Leave the work in the drop and walk away; the powered-off machine catches up on its own.

How it works

<shared-folder>/                     (any rclone remote: Drive, S3, Dropbox…)
├── 00-START-HERE.md                 onboarding for a new machine
├── PROTOCOL-CHANGES.md              append-only changelog, watched by hash
├── laptop/
│   ├── capabilities.md              what this machine can do (hand-written)
│   ├── inventory.md                 what it knows (index; optional generator)
│   ├── last-sync.txt                when it last ran a cycle (its heartbeat)
│   └── inbox/
│       └── handled/                 requests it has completed
├── desktop/
└── server/

A small sync.sh runs on a timer (systemd / cron / launchd) on each machine and does four things — and nothing that touches another machine's data:

at their inboxes to see which of this machine's own requests are still unhandled

1. pulls this machine's inbox/
2. detects new requests (and protocol changes) → raises a local SIGNAL.md flag
3. pulls every other machine's capabilities.md and last-sync.txt, and looks

1. publishes this machine's own descriptors (only when changed) and its heartbeat

It never executes a request. It fetches and flags; the agent does the work in a session.

Demo

Your desktop needs something only the laptop can do, so it drops a request in the laptop's inbox and forgets about it:

desktop$ echo "Compile the arm64 build and report the sha256." \
           > 2026-08-09-from-desktop-compile.md
desktop$ rclone copy 2026-08-09-from-desktop-compile.md \
           "gdrive:coordination/laptop/inbox/"

The laptop is asleep. Hours later it wakes; its timer fires a sync:

laptop$ ./scripts/sync.sh
14:17  1/4 pulling laptop/inbox …
14:17  2/4 detecting new requests and protocol changes …
       -> new requests; raised SIGNAL.md
14:17  3/4 pulling fleet capabilities …
       -> desktop: fetched
14:17  4/4 publishing my descriptors (only if changed) …
14:17  done.
# exit code 10 = "something new for you"

laptop$ cat ~/.agent-coordination/SIGNAL.md
# SIGNAL — something is waiting for you
## New requests in your inbox (~/.agent-coordination/inbox/)
- `2026-08-09-from-desktop-compile.md` (41 bytes)

Shortened. The full README is on GitHub.