
Why Remote MCP Servers Break When Tools Touch Files
TL;DR: MCP works fine remotely until tools need to read or write files. Then the shared-filesystem assumption breaks: remote servers cannot access client files, and generated artifacts get stranded on the server. I built remote-mcp-adapter to stage client files, capture tool outputs, and make remote MCP servers behave more like local ones. Most MCP demos look clean when everything runs on one machine. A tool reads a PDF, writes a screenshot, exports a file, and hands something useful back. No drama. No one thinks too hard about where files are coming from or where they end up. Then you move the MCP server somewhere remote and the illusion dies. I ran into this while working on a project to centralize MCP servers for an organization. On paper, MCP over HTTP feels straightforward. Put servers in containers or on a remote box, connect a client, and done. Except not really. Because a lot of useful MCP tools quietly assume one thing: the machine calling the tool and the machine executing th
Continue reading on Dev.to
Opens in a new tab


