After giving access to my local LLM file system, I left Claude Code

Claude Code has quickly become the go-to tool for many people when they need to manage things that aren’t actually coded. I’m mainly talking about computer admin like renaming files in bulk, running Obsidian vault, organizing stray folders, or quick bookmark cleanups that no one wants to do manually. It really is brilliant and there aren’t many complaints about it.

Except for one thing. Every file it touches is read in the chat and sent to Anthropic’s servers as part of that session. For a code folder, most people won’t think twice about it. For a folder of tax documents or medical PDF files, it gets a little harder to love the arrangement. This is where a local LLM with file system access comes in…

What is the MCP file system?

A configuration file that turns the local LLM into a file manager

The file system you mount is called the MCP server. It’s a small Node.js server published on npm as @modelcontextprotocol/server-filesystem , and it’s ironically run by the MCP team at Anthropic, so it’s not going away anytime soon.

What it does is actually give the model you’re working with a set of tools tap the files in the folder you specified. Reading, writing, editing, moving, renaming, searching, pulling metadata, listing the directory tree, the list goes on, all with different previews before doing anything. It comes with a sandbox, so the model only sees the folder you point it to, so nothing outside of that path can be accessed.

Installing it in LM Studio (my daily driver) is just a mcp.json edit and restart. Jan has the filesystem in the default MCP server list, so you’ll just enable it from the settings. llama.cpp has an MCP client built into the web UI (not the backend itself) that you enable with –webui-mcp-proxy. Ollama is weird: it doesn’t talk to MCP natively, so you’ll need a bridge like MCPHost or ollmcp to get there.

{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": (
"-y",
"@modelcontextprotocol/server-filesystem",
"ENTER YOUR DIRECTORY"
)
}
}
}

If you’re already running local LLMs seriously, this probably isn’t new information, but I think it’s the missing piece for most people who haven’t chatted with their files in the past.

Why am I accessing the local filesystem over Claude Code?

Three things that changed the way I use Local LLM

The privacy thing is where I want to start because that’s what really changes my default settings. Claude Code sends every file it reads to Anthropic’s servers as part of a conversation, and depending on your data settings, that data is stored for either five years or thirty days if you opt out. There’s at least one recently reported emergency injection exploit in the way of Claude’s Code Interpreter, which I don’t think should be blown out of proportion, but it kind of reinforces the issue of keeping private folders local. None of this is me saying that Claude’s code is bad, just that some files are probably best kept on your own hardware.

Another thing I would like to mention is that this really changed my thinking about domestic LLMs. Before I added the MCP filesystem, my native model was a boxed chatbot. I could talk to him, drop a file and get a response. But adding filesystem access turned those same models into something that actually did things on my disk. Same model, same weights, same VRAM footprint, but the difference is the tool access.

Model selection is important here. Tool summoning is a special skill, and not every small model has it. The Qwen family has been consistently strong at this, and I’ve been running Qwen 3.5 9B on 8GB of VRAM with multi-stage sequencing without issue. The Gemma 4 is also a huge leap forward in instrument calling accuracy compared to its predecessor.

Claude Code is still better suited for actual coding and agent development work. But for “look at this folder and tell me what’s in it, then categorize it”? A local model with file system access does the same job at zero cost, with no data transfer or speed limits. The biggest limitation here will be your hardware.

What this stack can and cannot do on my hardware

It’s more than just transferring files

Admin jobs are where I live. Point it to a cluttered folder, ask it to look at what’s in it, suggest categories, create subfolders, and move files into them. If the model handles multi-step calls without confusion, it will do so in one sequence. Renaming is another convenient task that I now hand over to the local LLM.

It goes further than porting and renaming tools. The MCP file system can read text files as a whole or by specific ranges of lines, write new ones, and perform line-based edits with different previews before doing anything. So it can actually overwrite the contents of your markup, YAML frontmatter, plain text configurations, or any other text-based files. For example, you can bulk update the frontend in the Obsidian repository or rewrite the logs folder to match the new template. It can technically read PDFs too, although it depends on the model whether it handles extraction well, so I wouldn’t be too sold on it.

There is a hardware reality check though. Tool calling is more demanding than normal chat, and if you’re on something like 6GB of VRAM, you’ll be running smaller models where multi-step reliability drops. With Qwen 3.5 9B, my 8GB feels like about the floor for confident chained sequences. Underneath that, you can still get useful single-tool calls, maybe not quite the experience to sort through the entire case end-to-end. Honestly, that’s more than most people ask of their local model.

Something missing from my local LLM setup

Claude Code is still my go-to tool when things get really complicated. If we’re being honest with ourselves, nothing in my local stack matches it. But most of the things I opened Claude Code with were actually computer admin, not for development workflow. This filesystem MCP made me realize how much of my day is being pushed to the wrong tool by the size of the job.