Cursor IDE File Transfer, Powered by MCP

When Cursor's agent runs a build, executes a test suite, or generates a bundle analysis, the useful output is often a file — a zip, an HTML report, a screenshot from a Playwright run. Normally that artifact just sits in your working directory until you go find it manually. With a file transfer tool available, the agent can proactively hand it to you as a link the moment it's ready, including to a device other than the one Cursor is running on.

Cursor reads MCP server definitions from a .cursor/mcp.json file, either at the project root (scoped to that repository) or in your global Cursor configuration (available across all projects). Add an entry under mcpServers:

{
  "mcpServers": {
    "srift": {
      "command": "srift",
      "args": ["mcp"]
    }
  }
}

Reload the Cursor window (or restart Cursor) so it picks up the new server. SRIFT's 15 tools — including srift_quick_share — become available to the agent immediately afterward. No global install? Use "command": "npx" with "args": ["-y", "srift-transfer", "mcp"].

Imagine asking Cursor's agent to fix a failing end-to-end test. It edits the code, reruns Playwright, and the run produces a trace file and a handful of failure screenshots. Instead of you digging through the test-results folder to find the right file, the agent can call srift_quick_share on the trace archive the moment it finishes, and hand you a link right in the chat panel. If the fix didn't work, you can open the trace on a second monitor or a tablet without leaving your editor's focus.

The same pattern applies to build artifacts: after a production build finishes, the agent shares the output bundle directly rather than you needing to locate it inside dist/ or .next/ manually.

It's also useful for cross-device review: an agent working in Cursor on your desktop can share a generated design mockup or a mobile screenshot render, and you can pull it up on your phone to check how it actually looks on a real device, rather than only viewing it in a desktop preview pane.

You can prompt naturally: "run the test suite and share the coverage report with me" or "send me a link to the production build." The agent calls srift_quick_share (parameters: filePath or filePaths, plus optional bundle, bundleName, exclude, sessionName, maxDownloads, ttlMs, encrypt, password) and returns a https://srift.app/d/<token> relay link — the file streams from your machine on demand and nothing is stored on a server — open it on your phone to check a screenshot, or on a different machine entirely, without emailing yourself a file or pushing to a branch just to move it around.

Project-scoped vs. global setup

If you only want this available for repositories that regularly produce shareable artifacts (build pipelines, data exports, generated docs), keep the config in that project's .cursor/mcp.json rather than your global settings.

Cursor's agent sometimes runs over SSH, in a dev container, or as a background agent in a cloud sandbox where local servers or background processes are not allowed. SRIFT handles this on its own: when the background daemon can't start (EPERM on bind, detached spawn or loopback blocked, port taken), srift mcp runs 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.

From the terminal, srift quick-share <file> behaves the same way: run it in the background (it exits after the download) or add --wait to block until the file is downloaded (--wait-timeout 30m exits with code 3 on timeout). --foreground forces in-process serving. srift doctor reports which transport is blocked and how to fix it, and srift get <url> downloads where curl is broken. Blocked UDP never breaks a link: the WebSocket relay on 443 is the fallback.

Cursor caches its MCP tool list per session, so a plain reload of the editor window is usually enough — if that doesn't work, fully quitting and reopening Cursor forces it to re-read .cursor/mcp.json from scratch. If the srift command isn't found, make sure it's installed globally (npm install -g srift-transfer) rather than only as a local project dependency, since Cursor spawns the MCP server as its own process outside your project's node_modules/.bin path resolution.

It's also worth checking that only one mcp.json is in play — a project-level file and a global one with conflicting entries for the same server name can cause Cursor to load the wrong configuration silently.

Finally, run srift doctor — it checks the daemon, HTTPS, WebSocket and UDP reachability and prints the exact fix. If the daemon can't start at all (common in sandboxes), srift mcp serves in-process automatically, so the tools still work.