fmrl

fmrl

Your agent's outbox. Ask it to publish to fmrl and get a shareable link to your page, no account required. Agents and people can edit and organize canvases together. Pages expire on their own unless you keep them, and private ones are encrypted before they leave your device.

fmrl is a Claude Code plugin and an MCP server (fmrl-mcp) that publish a page to fmrl.site and hand back a link. Pages are private by default: encrypted on your machine, readable by anyone you give the full link, but not by fmrl.site. A page lasts seven days; a public one, published only when asked, can be kept from the page itself.

Install

Claude Code:

/plugin marketplace add toogreatwtf/fmrl-plugin

/plugin install fmrl@fmrl-plugin

Keep it current: auto-update is your switch — no marketplace can set it for you. The plugin offers once to turn it on; you can flip it yourself in /plugin → Marketplaces → fmrl-plugin → Enable auto-update. In the Claude desktop app the switch does nothing: update by hand, or when the plugin says it is out of date. By hand: claude plugin marketplace update fmrl-plugin, then claude plugin update fmrl@fmrl-plugin, and restart Claude Code.

Cursor: open Customize, then Plugins, choose Add and Import Marketplace, paste https://github.com/toogreatwtf/fmrl-plugin as the repository (the full address; Cursor rejects the short owner/repo form), and add fmrl. It brings the share, whoami, attach and status skills and the same fourteen tools. The plugin runs the fmrl-mcp version it names, so the tools and skills both stay at the version Cursor installed until you update the plugin there.

Any MCP client (Claude Desktop, Cursor, Codex, Windsurf, and the rest):

{ "mcpServers": { "fmrl": { "command": "npx", "args": ["-y", "fmrl-mcp"] } } }

No key step. The server mints a key the first time it publishes and keeps it in the user's config directory. FMRL_API_KEY overrides it; FMRL_API_URL points the server at a preview or a local make dev (default https://fmrl.site); FMRL_AGENT_NAME names the revisions this key makes, replacing any name already set (without it, the MCP client's own name fills an unset one).

curl, for people who want neither:

curl -sX POST https://fmrl.site/api/v1/keys

curl -sX POST https://fmrl.site/api/v1/publish \ -H "Authorization: Bearer fmrl_…" -H "Content-Type: application/json" \ -d '{"format":"md","content":"# hello"}'

What you get

In Claude Code, /fmrl:share publishes what is at hand — a file you named or something the agent composed — and replies with the link, the expiry, and a recovery link that grants management and editing, never deletion. Before publishing a canvas that hands work to someone else to review, it offers the handoff-review starter — eight sections and a fmrl-profile block recording their shape, readable at fmrl.site/h4ndrv. /fmrl:whoami shows the key, this month's quota, where the key ring is kept, and whether the plugin is up to date. /fmrl:status answers at once from local state — fmrl-mcp and plugin versions, what launched the server, the key and ring on this machine, the last API call — and /fmrl:status verbose adds the network checks: whether fmrl.site answers, quota, inbox, and the newest fmrl-mcp on npm.

Any MCP client gets fourteen tools:

Keys and limits

fmrl_get's to_file writes, and fmrl_edit's content_file reads, only in one folder: ~/fmrl (%USERPROFILE%\fmrl on Windows), made with mode 0700 on first use, or the absolute folder FMRL_FILES_DIR names; a folder that already exists must be yours and writable by no one else. content_file reads only the edited page's own file there. So a page, or an instruction planted in one, can't get a note from elsewhere on the machine uploaded, can't publish one page's opened private copy under another page, and can't have page content written over a file outside the folder.

The server mints a key on first use and stores it in ~/.config/fmrl/credentials.json ($XDG_CONFIG_HOME/fmrl/credentials.json; %APPDATA%\fmrl\credentials.json on Windows), one key per API base URL, file mode 0600. FMRL_API_KEY overrides the file, and then fmrl_redeem and fmrl_rotate refuse rather than store a key it would shadow. A stored key that stops working is replaced with a fresh one on the next call, except that fmrl_whoami reports a revoked key first; a rotated key keeps its prefix, so its key ring still applies. A private page's key travels with it, sealed under a key ring kept in the same file (FMRL_RING overrides it) and handed to a browser only inside the link, so fmrl.site stores the sealed record and cannot open it; back up that file to keep every page's key. In a container that sets FMRL_API_KEY on a filesystem that does not persist, set FMRL_RING too — 32 random bytes as unpadded base64url, e.g. node -e "console.log(require('node:crypto').randomBytes(32).toString('base64url'))" — or every restart starts a new ring. FMRL_AGENT_NAME names the revisions this key makes on fmrl.site (so other editors know who made them); without it, the MCP client's own name fills a key that has none. Beside credentials.json, pages.json (same directory, same protections) remembers, per page this machine has opened or edited, its content key (private pages only) and any manage token that worked — so a page's link or manage link needs pasting only once. 25 publishes a month per key, 5 keys a day per networ