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, current spec dated 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 14 tools, grouped into three 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 end-to-end encrypted, plus srift_read_state for a snapshot of session state.

Hosted endpoint (https://srift.app/mcp) exposes the 8 session/peer orchestration tools only — those that don't require filesystem access or E2EE key material. For file transfer and chat, use the local daemon or the REST API's /quick-share endpoint.

In practice, srift_quick_sharecovers the large majority of agent use cases: it creates a session if one doesn't exist yet, seeds the file, and hands back a link — no multi-step session negotiation required.

MCP standardizes error reporting through JSON-RPC error codes, and Srift's server maps common failure modes to specific codes an agent can act on: -32000 means no active session exists yet, so the agent should call srift_start_session or srift_join_session first; -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 8 core 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:3822and exposes all 14 tools over stdio (for desktop agent clients like Claude Desktop or Cursor) and Streamable HTTP, per the MCP 2025-06-18 transport spec. Because it's local, there's no API key or OAuth — add an entry pointing at the srift CLI binary with the mcpsubcommand 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 — and the encryption model — is identical.