Claude Desktop MCP setup: pointing the app at your own folders

The app is installed, the conversation works, and then comes the first request that involves an actual file on the disk. Nothing happens, because a chat window has no idea what is in the Documents folder. That is the moment most people search for claude desktop mcp, and the answer is a protocol plus a small amount of configuration that decides, quite literally, which directories a model is allowed to touch.

The setup itself takes about ten minutes. The decisions inside it, which folders to grant and what to do about the approval step, are what determine whether the arrangement is still in use a month later.

What the protocol adds to the app

The Model Context Protocol is a standard way for a program running on a machine to offer tools to an AI application. The program is called a server, it runs locally as an ordinary process, and the application starts it on launch. Once connected, the model can call the tools the server exposes.

The official filesystem server is the one most people want first. It provides tools for reading file contents and directory structures, creating files and directories, moving and renaming files, and searching by name or content. Every one of those operations is presented for approval before it runs, so nothing is moved without a click.

Two properties of this arrangement are worth understanding before the first server is added. The documentation states plainly that the server runs with the same account permissions as the person who started it, which means it can perform any file operation that could be performed by hand. And the list of directories is passed to the server as arguments, so the boundary is set at configuration time rather than negotiated during a conversation. The configuration file is the security boundary, not the approval dialog.

Servers come in two kinds. Local servers run on the machine and reach local resources. Remote servers run somewhere else and reach a service over the network. This guide is about the local kind, which is what file access requires. The distinction also decides where a failure can come from: a local server breaks because of a path, a runtime or a permission on this Mac, while a remote one breaks because of a token or an outage somewhere else.

Two ways to install, and when each is right

There are two supported routes, and they suit different situations.

Route	How it is installed	Best for
Desktop extension	Settings, then Extensions, then Browse extensions, then Install	Reviewed servers, no JSON, settings prompted in the interface
Configuration file	Settings, then Developer, then Edit Config, then restart	Servers not in the directory, custom arguments, several servers at once

Desktop extensions package a local server so it installs in a single click, in the same way a browser extension does. Any required settings, such as an API key, are collected through the interface instead of being typed into a file. A custom extension distributed as an .mcpb file is installed from the same screen, under Advanced settings, in the Extension Developer section.

On Team and Enterprise plans, the owner controls this list. Public extensions can be enabled or disabled for the organisation, and custom extensions can be uploaded and made available to members. Machine-level enterprise policy overrides anything set inside the app, so a managed Mac may simply not offer the screen at all.

The configuration file is the route with no ceiling. It is where a server that nobody has packaged goes, and it is the only route that takes arbitrary arguments, which is exactly what granting specific directories requires.

Setting up the filesystem server

The steps below are the documented path for the configuration file route on macOS.

Open Settings from the Claude menu in the menu bar, not from inside the conversation window, then choose the Developer tab and click Edit Config. That button creates the file if it does not exist and opens it if it does. On macOS it lives here:

~/Library/Application Support/Claude/claude_desktop_config.json

The contents describe which servers to start and how. A filesystem server granted two directories looks like this:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/username/Desktop",
        "/Users/username/Downloads"
      ]
    }
  }
}

The name filesystem is a label that appears in the app. The command runs the package with npx, which requires Node.js to be installed; node --version in a terminal confirms that. The -y flag accepts the package installation without prompting. Everything after the package name is a directory the server may access, and username has to be replaced with the real account name.

Save the file, then quit the application completely and open it again. A restart is not optional here: the configuration is read at launch, so an app left running will show nothing new.

To confirm the connection, click the indicator at the bottom left of the message box, hover over Connectors, and choose Manage connectors. The server appears there by the name given in the file, and selecting it lists the tools it provides. If it is missing, the configuration was not loaded, and the next section applies.

Choosing which directories to grant

This is the decision that matters, and it is made once, in the args array.

The temptation is to pass the home directory and stop thinking about it. That grants read and write access to the browser profile, the SSH keys, the mail store, and everything else that happens to live under the same account. The documentation's own note on this is worth taking at face value: grant access only to directories that are genuinely acceptable to have read and modified.

A more durable pattern is to create the boundary deliberately. One working directory, named for the purpose, containing the projects currently in flight. Adding a folder later is a two-line edit and a restart, which is cheap compared with explaining why an agent read something it should never have seen.

Three directories are worth granting early because they carry the most repetitive work. Downloads, because that is where the mess collects. A scratch or inbox folder, because moving files into it is how a person signals what is in scope. And the specific project folder currently being worked on.

Two are worth keeping out on principle. The home directory itself, for the reasons above, and any folder that syncs to a shared drive where a rename propagates to other people within seconds.

When it does not connect

The failure is almost always one of five things, and the logs say which.

Log files are written to ~/Library/Logs/Claude. The file mcp.log covers connection attempts and failures in general. A file named for a specific server, in the form mcp-server-NAME.log, carries that server's own error output. Following both while restarting the app is the fastest diagnosis available:

tail -n 20 -f ~/Library/Logs/Claude/mcp*.log

Check the JSON first. A trailing comma or a missing brace makes the whole file unreadable, and the app has no way to tell which server was intended. Second, check that every path in the file is absolute. Relative paths and shell shortcuts do not expand here, so a path beginning with a tilde will not resolve. Third, run the server by hand in a terminal with the same arguments that are in the file; if it fails there, it will fail in the app, and the error is visible immediately:

npx -y @modelcontextprotocol/server-filesystem /Users/username/Desktop /Users/username/Downloads

Fourth, confirm that npx can actually install packages, which requires npm to be present globally. Fifth, if tools appear but calls fail silently, restart the application once and then read the server's own log file rather than guessing.

What a working setup looks like on the first day

A connected server is not the same as a useful one, and the difference shows up in what gets asked of it.

Three requests are worth running immediately, because each exercises a different tool and each has an answer that can be checked by eye. Ask for a summary of what is in the granted folder, which tests the directory listing. Ask which files in it were changed most recently, which tests reading file metadata rather than guessing from names. Then ask for a plan to tidy it, without applying anything, which tests whether the model can see enough to be specific. A plan that names real files is a sign the grant is correct. A plan that describes folders in general terms means the model is working from the request rather than from the disk.

The first write is the one to watch. Something small and reversible is the right test, such as creating a single text file in the granted directory, and the approval prompt that appears is worth reading properly rather than clicking through. It names the operation and the path, and that pairing is what needs checking: the correct operation on an unexpected path is the failure mode that matters.

After that, two habits keep the setup honest. Keep a copy of the configuration file somewhere outside the application's own folder, because it is the record of what has been granted and it is easy to forget after a few edits. And re-read the directory list whenever a project ends, since folders tend to accumulate in that array and nothing prompts a review. A grant that made sense for one client in March is still live in September unless somebody removes it. Treating that array as a list with an owner, rather than as settings that were configured once, is the whole of the maintenance this setup needs.

Where this setup stops being enough

After a week of real use, two limits show up, and neither is a bug.

The approval step is per action. That is the right default for anything destructive, and it becomes friction when the task is thirty renames that were all going to be approved anyway. The workaround is not to remove the approvals: it is to have the model produce a list of proposed changes, read the list once, and then apply it with a single command.

The second limit is that a conversation is not a file view. Reading a directory listing as text is a poor substitute for seeing it, and checking a result means switching to the Finder and back. That is why this path tends to end with folders, a terminal and an agent kept in one window, where the current folder is the context and the result of an action is visible without changing applications. The comparison with other file managers sets out where that helps and where an editor or a notes app is still the better tool.

What to change first

Add the filesystem server with exactly one directory, the one holding this week's work, and use it for three real tasks before widening the grant. If the approval prompts are the thing that wears thin rather than the capability, the missing piece is a window where the folder and the agent are already side by side, which is what Atriens is for.