Permissions and access

Limit each hosted MCP server to the access it needs

You will scope each MCP server to only the directories and credentials it needs, and check that the paths it reports match what you configured. This reduces risk if a server is compromised or misbehaves.

  1. Inventory serversList each server and what it needs
  2. Narrow the rootSet one project directory per filesystem server
  3. Verify allowed pathsCheck list_allowed_directories and letter case
  4. Scope credentialsOne token per server, minimal permissions
  5. Recheck after upgradesConfirm paths again after each package change

Why it matters

MCP servers run with the permissions of the user that launches them, so anything they can reach is reachable by the agent calling them. A filesystem server configured with a broad root can read far more than a project needs. Even a correctly scoped server can misreport its own allowed paths: a published @modelcontextprotocol/server-filesystem build was reported to lowercase every allowed path, so /Users/ido/Dropbox/Work was listed as /users/ido/dropbox/work and then failed on a case-sensitive filesystem (source (opens external site)). Scope access on purpose and verify what the server actually enforces.

Steps

  1. List every MCP server in your client config and write down the directories, tokens and accounts each one needs. Drop any server you do not use today.

  2. Point filesystem servers at the narrowest project directory, not your home folder or a cloud sync root. Pass that path as an argument in args, for example:

json
{
  "mcpServers": {
    "filesystem": {
      "command": "C:/Program Files/nodejs/node.exe",
      "args": [
        "C:/Program Files/nodejs/node_modules/@modelcontextprotocol/server-filesystem/dist/index.js",
        "C:/Users/you/projects"
      ]
    }
  }
}

This Windows form with the absolute node.exe path is the workaround commenters used to get npx-based servers connecting (source (opens external site)). Adjust the paths to your machine.

  1. Ask the server what it allows. Use the filesystem server's list_allowed_directories tool and confirm each entry matches the path you configured, including letter case.

  2. Test one read and one list against the allowed directory. If a path fails with a parent-directory error, check case first, since case-sensitive volumes break on lowercased paths (source (opens external site)). Keep the path case exactly as on disk.

  3. Give each server its own token or credential with the smallest scope that works. Do not reuse a broad personal token across servers.

  4. When you run the MCP Inspector to test a server, use the official image ghcr.io/modelcontextprotocol/inspector:latest rather than the older Docker Hub image (source (opens external site)). Pin a versioned tag if you need reproducible runs.

  5. Rotate any token that was shared with a server you have since removed, and re-check the allowed list after each package upgrade.

Common mistakes

  • Pointing a filesystem server at your home directory because it is convenient.
  • Assuming the configured path is the enforced path without checking the reported list.
  • Reusing one broad token across several servers.
  • Installing a server with npx at an unpinned version and never checking what changed.

Checklist

0 of 7 done

Sources

  1. server-filesystem lowercases allowed paths and fails on case-sensitive filesystems
  2. Claude Desktop MCP servers using npx fail to connect on Windows; fix by using absolute node.exe path after global install
  3. How do I run MCP Inspector as a Docker image instead of npx?
Was this guide useful?