Quick assessment

Partly correct: installation friction made remote MCP servers attractive, but Claude Desktop now supports one‑click local MCP installations via Desktop Extensions, which reduces the need to rely on remote URLs only.[1]
Not correct as stated that clients “can’t” send/receive files: Claude Desktop can read, write, move, and search local files via the official filesystem MCP server, so file transfer is possible when a local MCP is connected.[2][3]
Protocol nuance: MCP “resources” are a read API that can return text or binary blobs; writes and uploads are intentionally handled via server‑defined tools rather than a built‑in file‑upload primitive, so cross‑client uploads aren’t standardized at the protocol level today.[4][5]
Viable today: many community and vendor MCP servers already implement upload/download patterns or bridges (e.g., generic “upload-file” servers and file‑ops integrations), so CRUD‑style workflows are feasible without waiting for protocol changes.[6][7][8]
Your current approach (server fetches a remote URL and hands the file to another tool like Figma) is a common and sound pattern within MCP’s model of using tools and resources.[5]

What’s actually available today

Local file access through Claude Desktop: Add the filesystem MCP server and Claude can read/write/move files under user‑approved directories, enabling the assistant to ingest and produce local files directly.[3][2]
Resources are read‑only but blob‑capable: Servers can expose file contents and other binary data as base64 “blob” resources for clients to read and route into downstream tools.[5]
Upload/download via tools: Because writes aren’t part of the resources API, servers expose tools for uploads or use storage backends; several community servers implement generic HTTP upload so assistants can hand off files programmatically.[7][6]
Turnkey file bridges: Some MCP servers front full file‑transfer platforms, exposing upload/download, folder listing, and sharing within a controlled, audited environment.[8]
Easier local installs: Desktop Extensions package an MCP server and all dependencies into a .dxt for one‑click install in Claude Desktop, removing most Node/Python setup pain that motivated a “remote‑only” stance.[1]

Connect Claude Desktop to the filesystem MCP server to access local files, then call an MCP tool that uploads the selected file to cloud storage and returns a shareable URL; this leverages resources for reading blobs and tools for writes.[2][5]

Provide a tool that returns a presigned POST/PUT and any required form fields; the app or user performs the upload, and the server ingests the resulting URL for downstream use; community “upload‑file” servers follow this model and are plug‑and‑play in MCP configs.[6][7]

Use an MCP server that wraps a file‑transfer/storage service to handle authenticated upload/download, directory queries, and link sharing through audited APIs.[8]

MCP encourages read access via resources and action via tools; there is no single “standard file upload” primitive across clients, so file handling is intentionally left to server tools or client UX, which matches your observation that uploads are out of scope for the base resource model.[4][5]

The friction point about local installs was real, but it’s eased significantly by Desktop Extensions, so “remote URLs are the preferred way” is no longer universally true for Claude Desktop users.[1]
“It can’t send and receive files” is too strong; Claude Desktop plus the filesystem MCP server does exactly that for local files, and uploads are handled via server tools or storage bridges rather than the resources API itself.[2][5]
Shipping an upload tool or using a generic “upload-file” MCP server is a practical way to get CRUD‑style file workflows today, and your current URL‑fetch pattern is aligned with how MCP is designed to compose tools and resources.[7][6][5]