How to find MCP servers on developer machines

To find MCP servers on developer machines, open the config file each coding agent keeps: ~/.claude.json and .mcp.json for Claude Code, ~/.cursor/mcp.json for Cursor, .vscode/mcp.json for VS Code and GitHub Copilot, ~/.codeium/windsurf/mcp_config.json for Windsurf, and ~/.codex/config.toml for Codex. Each file lists every server the agent starts, the command it runs, and the folders or tokens it gets. Checking those files takes about two minutes on one laptop. The hard part is doing it across a whole team, and knowing what to look for once you have the list.

Where each coding agent stores its MCP servers

Every agent that speaks the Model Context Protocol reads its servers from a file on disk. Most agents have two levels: a user file in the home folder that applies everywhere, and a project file inside a repository that applies only there. The project file matters more than it looks, because it is committed to git and arrives on every machine that clones the repo.

Paths come from each vendor's documentation, listed under Sources. Agents change their settings often, so check the docs again before you build a script around them. VS Code can also be set to read the Claude Desktop, Cursor and Windsurf files, which means one server can show up in several agents at once.

How to find MCP servers on developer machines in two minutes

On a single Mac or Linux laptop, these commands print every MCP config file in the usual places, then search the home folder for project files in cloned repositories. Nothing here changes a file.

ls -la ~/.claude.json ~/.cursor/mcp.json ~/.codeium/windsurf/mcp_config.json \
  ~/.codex/config.toml ~/.copilot/mcp-config.json \
  "$HOME/Library/Application Support/Claude/claude_desktop_config.json" 2>/dev/null

find ~ \( -name ".mcp.json" -o -path "*/.cursor/mcp.json" -o -path "*/.vscode/mcp.json" \) \
  -not -path "*/node_modules/*" 2>/dev/null

On Windows, the same search in PowerShell looks like this:

Get-ChildItem -Path $HOME -Recurse -Force -ErrorAction SilentlyContinue `
  -Include mcp.json,.mcp.json,mcp_config.json,claude_desktop_config.json

If Claude Code is installed, claude mcp list shows every server it will load from the current folder, and claude mcp get name shows one in detail. In Codex, the /mcp command inside the app lists connected servers. Cursor shows its servers in its settings and writes connection logs to the Output panel under "MCP Logs".

What to record for each MCP server you find

A list of names is not enough to judge risk. For each server, write down five things, all of which are in the config entry itself.

The first is the command and package. Most local servers start with a line like npx -y some-package or uvx some-package. The package name tells you who publishes the code, and that is where impersonation happens. The second is the version. A command with no version number, or with @latest, downloads whatever was published most recently every time it starts. That is how a single bad release reaches every machine at once.

The third is what the server can reach: folder paths in its arguments, API tokens in its environment, and whether it gets a shell. A filesystem server given / or the whole home folder can read SSH keys and .env files. The fourth is the transport. A command entry runs a program on the laptop over stdio, while a url entry connects to a remote server over HTTP. Remote servers need an address you recognize and HTTPS. The fifth is the scope: user, local or project. Project servers deserve the closest look because they are shared.

Add two columns that are not in the file: whose machine it is on, and which repository a project server came from. When a server turns out to be risky, those two answers tell you who to talk to and how far it has spread. Without them, a finding is a package name and nothing to act on.

Why project files like .mcp.json need the closest look

A project-level file means a server can arrive on a machine without anyone choosing to install it. Clone a repository with a .mcp.json or .vscode/mcp.json in it and the agent will find those servers the next time it opens the folder.

Agents put a check in front of this, but not everywhere. Claude Code asks for approval before it uses project servers in an interactive session. Its documentation also notes that in non-interactive runs, such as claude -p and the Agent SDK, that prompt cannot be shown and project servers load without asking. VS Code ties workspace MCP servers to Workspace Trust. So the safety of a project file depends on how the agent is run, which is a good reason to review these files in pull requests the same way you review a new dependency. Each agent has its own settings beyond MCP, covered in our guides to Claude Code security risks, Cursor security risks and GitHub Copilot security risks.

Signs an MCP server on a developer machine needs a closer look

Most servers you find will be fine. These patterns are the ones worth stopping on. A package name that is close to a well-known brand but published by someone else is the first, because that is exactly how the postmark-mcp attack worked. An unpinned version is the second. Secrets typed straight into the config file are the third; VS Code's documentation says plainly that a personal configuration file is not a secret store. Broad access is the fourth: a whole drive, a shell, or a token with admin scope. A remote URL on a host nobody recognizes is the fifth.

For any server that matches one of these, look it up on the NoFly list before deciding. Our write-up of every malicious MCP server reported so far shows what each of these warning signs looked like in a real attack.

How to find MCP servers across a whole organization

Checking one laptop is easy. Checking two hundred is where teams get stuck, and it is a recognized problem: the OWASP MCP Top 10 lists shadow MCP servers as MCP09, servers running in an organization that security does not know about.

There are three practical ways to do it at scale. You can push a read-only script through your device management tool that collects the files in the table above and sends back the server entries, with secrets stripped. You can search your source code host for .mcp.json, .cursor/mcp.json and .vscode/mcp.json to catch every project-level server in one pass. Or you can run a NoFly Discovery Scan, which does both, joins the results into one inventory with who runs each server and where, and scores each server so the risky ones are at the top.

Plan for what the collection will contain. Config entries often hold tokens in their environment blocks, so strip any value that looks like a key before the data leaves the laptop, and store the inventory with the same care as any other secret-adjacent data. Tell developers what is collected and why; a read-only inventory of agent config is an easier conversation than a block that appears without warning.

Coding agents are one layer of a wider review. Our guide on how to find shadow AI in your organization covers the others, from SSO grants to network logs, and our comparison of shadow AI detection tools shows which kind of tool sees which layer.

Whichever you choose, run it on a schedule. New servers are added every week, and an inventory from last quarter is a list of what used to be there.

When you find a config that needs fixing, our mcp.json example shows a risky entry next to a safer one for each agent. For Windsurf in particular, see our notes on Windsurf security concerns.