Send Files From Claude Using the SRIFT MCP Server

Claude Code frequently produces artifacts worth keeping — build output, test logs, generated reports, screenshots from a browser automation run. Without a file transfer tool, the only way to get those out of a coding session is to have Claude read the file back into the conversation as text, which is lossy for binaries and wasteful for anything large. Registering SRIFT as an MCP server gives Claude a direct path: call a tool, get a link, hand it to you.

Claude Desktop reads MCP server definitions from its claude_desktop_config.json file. Add an entry under mcpServers with command set to srift and args set to ["mcp"]. Restart Claude Desktop so it picks up the new server — you should see SRIFT's tools appear the next time Claude lists available tools.

Claude Code supports the same stdio-based MCP transport. Register the server via Claude Code's MCP management command, or add it to a project-level MCP configuration file if you want it scoped to a specific repository — useful if you only want the file transfer tool available in certain projects, like ones that produce build artifacts you regularly need to share. For example: claude mcp add srift -- srift mcp, or claude mcp add srift -- npx -y srift-transfer mcp with no global install.

Claude Code often runs where local servers or background processes are not allowed: a locked-down sandbox, a container, a remote dev box or a datacenter runner. SRIFT handles this automatically. If the background daemon can't start (bind fails with EPERM, detached spawn or loopback is blocked, or the port is taken), srift mcp runs the daemon inside its own process and all MCP tools keep working. srift quick-share does the same from Bash: it opens no local port, needs only outbound HTTPS/WSS on port 443, keeps running until the file is downloaded and then exits.

• Run srift quick-share <file> in the background, or add --wait to block until the download completes (--wait-timeout 30m exits with code 3 on timeout).
• --foreground forces in-process serving; --keep-alive serves until the TTL expires.
• srift doctor names any blocked transport and the fix. Blocked UDP never breaks a link — the WebSocket relay on 443 is the fallback.
• srift get <url> downloads and decrypts where curl is broken; HTTPS_PROXY, NO_PROXY and NODE_EXTRA_CA_CERTS are honored.

Nothing is stored on a server in any mode: the link streams from the machine Claude runs on, so it works while that process runs.

Consider a long Claude Code session where the agent refactors a module, runs the test suite, and generates an HTML coverage report. Without a file transfer tool, checking that report means switching to a file explorer, finding the right nested output directory, and opening it manually. With SRIFT connected, you can just ask Claude for the link and open it immediately, even on your phone while away from your desk.

Or consider using Claude Desktop to analyze a dataset and produce a cleaned CSV or a chart image — again, rather than Claude trying to inline a large file's contents into the chat (which is both wasteful of context and sometimes simply not possible for binary formats like images or archives), it hands you a direct link instead.

Once connected, you don't need to reference tool names directly — just ask Claude in plain language, for example: "share the coverage report with me" or "send me that zip file you just built." Claude will call srift_quick_share under the hood (parameters: filePath or filePaths, plus optional bundle, bundleName, exclude, sessionName, maxDownloads, ttlMs, encrypt, password) and return a https://srift.app/d/<token> link. Open it in any browser, or fetch it with srift get <url> (or curl -fLOJ) from a terminal. Ask Claude to encrypt it for anything sensitive: the key stays in the link's #k= fragment and your browser decrypts locally.

A note on scope

SRIFT's MCP server runs locally and only shares files you or Claude explicitly point it at — it doesn't scan your filesystem on its own. The same zero-auth, zero-account model applies here as everywhere else in SRIFT: no API key to provision, no signup for either side of the transfer.

The most common cause is a config file that wasn't reloaded — Claude Desktop only reads claude_desktop_config.json at startup, so a full restart (not just closing the window) is usually required after editing it. The second most common cause is the srift command not being on the system PATH that Claude Desktop's process inherits; installing the CLI globally via npm usually resolves this. If tools still don't appear, run srift doctor: it checks the daemon, HTTPS, WebSocket and UDP reachability and prints the fix. In a sandbox that blocks the daemon, srift mcp serves in-process automatically.

If tools appear but a call to srift_quick_share fails, check that the file path Claude is passing is absolute rather than relative — the daemon runs as its own process and doesn't necessarily share a working directory with your terminal or IDE.