One folder, not your drive

Before you start

You need the Docker MCP Toolkit running. That’s the containers guide, about ten minutes.

Without it, the tool isn’t limited to what you granted. It runs as you, reaching everything you can reach. Do the containers guide first.

Decide the folder before you open anything

Do this on paper, not in a file picker. Once a dialog is open, the temptation is to pick whatever makes the demo work.

Ask three questions.

What am I actually trying to do this week? Not what might be useful one day. If it’s search my project notes, the answer is the project notes folder. Future needs get a future folder.

If everything in this folder were posted publicly, what would it cost me? Answer it honestly. Most people’s Documents folder fails this badly, because there’s a passport scan or a signed contract in there somewhere.

Whose data is in here that isn’t mine? Client files carry obligations you agreed to in writing. If a confidentiality clause covers that folder, pointing an AI tool at it may be a decision you’re not allowed to make alone.

The good answer is usually a folder you’d be comfortable screen-sharing on a call. If you’d hesitate to share it, don’t mount it.

Make a folder for the purpose, if you don’t have one

Most people don’t have a folder that passes step 1, because folders grow by accident. Making one is fine:

mkdir ~/ai-workspace

Copy in what the assistant needs. Copies, not the originals. This costs you a minute and it turns an open-ended risk into a closed one: whatever happens, happens to a folder you built on purpose.

It’s also the honest answer to the client-data problem. A copy of the three documents relevant to the job is a very different exposure from the whole client directory.

Add the Filesystem server

1. In Docker Desktop, open MCP Toolkit and select the Catalog tab
2. Find Filesystem
3. Select the checkbox next to it, then choose the profile to add it to from the drop-down. Pick the profile for this kind of work, not a general one

It carries a Requires Configuration label. That label is the whole guide: the server won’t run until you’ve told it which folder it can see.

Point it at exactly one folder

Open the server’s Configuration tab and give it the path to the folder you decided on in step 1.

What’s happening underneath is a mount: the folder is passed into the container, and the container is given that path as its allowed directory. Written by hand it looks like this:

{
  "mcpServers": {
    "filesystem": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-v", "/Users/you/ai-workspace:/projects/ai-workspace",
        "mcp/filesystem",
        "/projects/ai-workspace"
      ]
    }
  }
}

Two things to notice, because together they are the security model.

The -v line is the mount. Left of the colon is the folder on your machine, right of it is where the container sees it. Nothing outside that path exists as far as the container is concerned.

The path at the end is the allowed directory. The server holds itself to the directories it’s given. Not listed, not reachable.

Make it read-only if the assistant only needs to read. Just add :ro to the end of the mount:

"-v", "/Users/you/ai-workspace:/projects/ai-workspace:ro",

Most people’s use is reading, and most people never change this. Writing is a separate privilege. Make it a separate decision.

Test the boundary, don’t assume it

Everything is connected now, so you talk to it where you normally would: an ordinary chat in your assistant. The container is the gate; the chat is where you ask. This step is one question in that chat, and it takes ninety seconds.

Ask for something inside the folder. List the files you can see. You should get your folder’s contents.

Then ask for something outside it. Read my SSH config, or list what’s in my Downloads folder. You should get a refusal or an error, not a listing.

If it reads something you didn’t mount, stop and check the configuration before you use it for anything real.

Write down what you mounted and when. A line in a note is enough. In six months you won’t remember, and which tools can see this folder is a question that arrives at the worst possible time.

A boundary worth knowing about

Some AI clients support roots, where the client tells the server at runtime which directories are in play. When that happens, the client’s list replaces the allowed directories you set on the server.

Usually this is fine and often useful, since it’s how an editor scopes a tool to the project you have open. But it means the folder you set isn’t always the last word. If you’re leaning on this boundary for something that matters, test it inside the client you actually use, the way step 5 describes.

If you have staff

Everything above is one person making one decision. If other people use AI tools on company data, two things follow.

Somebody owns the list. Which tools have file access, to what, granted by whom. Not because a document prevents anything, but because without it nobody can answer the question when it’s asked.

“Nobody told them not to” is the usual cause. People connect tools to be better at their jobs. With no folder they’ve been told to use, they point at the whole drive, because that’s the default and it works. An approved folder is a five-minute job that removes the reason.

The short version

1. Decide the folder on paper. One you’d screen-share.
2. If nothing qualifies, make ~/ai-workspace and copy in what’s needed.
3. Catalog → Filesystem → Add to → your profile.
4. Configuration → that one folder. Add :ro if it only needs to read.
5. Ask it to read something outside the folder. Confirm it can’t.
6. Write down what you mounted.

Sources

• Docker MCP Toolkit — security model and filesystem access — how file mounts are granted per server
• Filesystem MCP server — Docker MCP Catalog — the Requires Configuration label and the filesystem.paths setting the server needs
• Filesystem server reference — modelcontextprotocol/servers — allowed directories, read-only mounts, and the roots protocol

Written August 2026. UI labels and mount behavior checked against Docker’s MCP Toolkit and catalog documentation on 23 August 2026. Docker Desktop ships roughly weekly, so the check date is more useful here than a version number.