An MCP File Transfer Server for AI Agents

An AI coding agent that just built a release archive, generated a test coverage report, or produced a rendered image has no good default way to get that file to the person it's working for. Pasting base64 into a chat response is slow, fragile, and often exceeds context limits for anything beyond a small image. A dedicated file transfer tool solves this by giving the agent a single function call that returns a link the human can open immediately.

MCP (Model Context Protocol; SRIFT speaks the 2026-07-28 revision and older ones such as 2025-06-18) defines a consistent JSON-RPC 2.0-based interface for agents to discover and call external tools, read resources, and use prompts — without every agent vendor needing a bespoke integration for every tool. An MCP-compatible client (Claude Desktop, Claude Code, Cursor, and others) can connect to any compliant MCP server and immediately see what tools it exposes via tools/list.

Local daemon (after npm install -g srift-transfer or curl | sh) exposes all 15 tools, grouped into four areas:

• Session management: srift_start_session, srift_join_session, srift_session_status, srift_close_session, srift_approve_join, srift_reject_join, srift_kick_user.
• File transfer: srift_send_file, srift_accept_transfer, srift_list_transfers, and srift_quick_share — the zero-install path that returns a public https://srift.app/d/<token> download link.
• Chat: srift_send_chat and srift_chat_history, both AES-256-GCM encrypted with the session key (participant-only when the session has a room secret), plus srift_read_state for a snapshot of session state.
• Diagnostics: srift_net_diagnose — the same connectivity report as srift doctor (HTTPS, WebSocket, UDP, proxy, sandbox detection) with the exact fix.

Hosted endpoint (https://srift.app/mcp) exposes 9 session/peer control tools only — those that don't require filesystem access or E2EE key material. For file transfer and chat, use the local daemon (MCP, or its REST /quick-share endpoint on 127.0.0.1:3822).

In practice, srift_quick_share covers the large majority of agent use cases. Its parameters are filePath or filePaths (up to 500), plus bundle, bundleName, exclude, sessionName, maxDownloads, ttlMs, encrypt and password. It returns a relay link: the bytes stream from the agent's machine through the srift.app relay on demand and nothing is stored on a server, so the link works while the daemon (or the MCP process) runs. With encrypt: true the key rides in the link's #k= fragment, which is never sent to the server, and the browser decrypts locally.

Many agent runtimes forbid local servers or background processes. When the background daemon can't start (bind fails with EPERM, detached spawn or loopback is blocked, or the port is taken), srift mcp hosts the daemon inside its own process and every MCP tool keeps working. It opens no local port and needs only outbound HTTPS/WSS on port 443. The switch is automatic, including when a running daemon becomes unreachable.

From a shell, srift quick-share does the same: it keeps running until the file is downloaded and then exits, so run it in the background or add --wait (--wait-timeout 30m exits with code 3 on timeout). --foreground forces in-process serving and --keep-alive serves until expiry. Blocked UDP never breaks a link because the WebSocket relay on 443 is the fallback. srift doctor (or the srift_net_diagnose tool) names any blocked transport, and srift get <url> downloads and decrypts where curl is broken. HTTPS_PROXY/NO_PROXY and NODE_EXTRA_CA_CERTS are honored.

When a SRIFT tool can't do its job it returns a normal result marked isError: truewith a plain-language reason the agent can act on, for example "No active session" (call srift_start_session or srift_join_session first). Protocol problems use standard JSON-RPC codes: -32602 means invalid parameters, prompting the agent to re-check the tool's input schema. For file-specific issues, a transfer stuck at 0% usually means the receiving peer hasn't called srift_accept_transfer yet, which an agent can detect via srift_list_transfers and surface to the user.

This matters because an agent that can only succeed or fail silently is much harder to build reliable automation on top of. Structured error codes let an agent retry, ask the user for clarification, or fall back to a different tool without guessing.

Path 1: Hosted endpoint (zero-install) — If you're using a browser-based agent (Claude.ai, ChatGPT, Perplexity) or a cloud deployment, connect directly to https://srift.app/mcp. No local daemon needed. Exposes 9 session/control tools (session orchestration and peer management); limited to operations that don't require filesystem access or E2EE key derivation.

Path 2: Local daemon (full capabilities) — Install srift via curl -fsSL https://srift.app/install.sh | sh or npm install -g srift-transfer. The daemon runs on 127.0.0.1:3822 and exposes all 15 tools over stdio (for desktop agent clients like Claude Desktop or Cursor) and Streamable HTTP. In a sandbox with no local servers, srift mcp runs the daemon in-process instead. Because it's local, there's no API key or OAuth — add an entry pointing at the srift CLI binary with the mcp subcommand to your client's MCP configuration file.

For desktop client setup, see the Claude MCP file transfer and Cursor MCP file transfer guides. Both use the local daemon path for complete file transfer + chat capabilities.

Because the server exposes a REST surface alongside MCP, it isn't limited to interactive IDE agents. A LangChain or CrewAI pipeline can wrap the same /quick-share endpoint as a function tool; an n8n or Zapier workflow can call it from an HTTP Request node after a file is generated somewhere upstream. The MCP tool definitions and the REST endpoints describe the same underlying operations, so whichever integration surface fits an existing stack, the behavior is identical. For sensitive files, pass encrypt: true so the relay only ever sees ciphertext.