How to find MCP servers in your codebase and clusters

To find MCP servers in a codebase, search repositories for .mcp.json files, the project-scoped server lists, then run claude mcp list on each developer machine. In a cluster, list pods across all namespaces and read each container image. Local and user-scoped servers never appear in a repository, so the search gives you a starting inventory, not a complete one.

Checked against the Claude Code MCP docs and the Kubernetes kubectl and Pod docs as of 2026-10-27.

Where MCP server configuration lives

Claude Code reads MCP servers from three scopes, and only one of them is in the repository. Local scope is the default. It stores the server under the project’s path in ~/.claude.json, so the same server does not appear in your other projects. User scope also uses ~/.claude.json, and it makes the server available in every project on the machine. Project scope writes to .mcp.json at the project root, and the docs suggest checking that file into version control so the whole team gets the same servers.

Scope	Where it is stored	Loads in	Found by a repository search
Local (default)	`~/.claude.json`, under the project path	Current project only	No
Project	`.mcp.json` at the project root	Current project only	Yes, if committed
User	`~/.claude.json`	All your projects	No

The entries themselves use a few keys you can search for. A remote server has a type and a url. A local server has command, args and env. Claude Code expands ${VAR} references in command, args, env, url and headers, so a URL built from a variable will not show its real value in the file.

{
  "mcpServers": {
    "shared-server": {
      "type": "http",
      "url": "https://example.com/mcp"
    }
  }
}

Search repositories for project-scoped servers

A repository search is the quickest way to find servers a team has deliberately shared. It will not find anything a developer added for themselves, because that lives on their machine.

Find every .mcp.json file at a project root across the repositories you own or scan.
Open each file and list the names under mcpServers.
For each entry, note whether it has a url (a remote server) or a command (a local server that runs as a process on the developer’s machine). The docs say that “Stdio servers run as local processes on your machine.”
Compare each url or command with the servers you approved. A name is only a label, so match on what the entry connects to or runs.
Record any ${VAR} values you cannot resolve from the file, and check them on a machine that has the variable set.

Be careful with approval. Claude Code asks before it uses project-scoped servers in interactive sessions, so a server from a new clone may wait for a person to click through. In claude -p runs and Agent SDK sessions, the docs say Claude Code “loads project-scoped servers without asking.” A repository can therefore start a server in a script or a pipeline with no one approving it, and the repository search is the only place you would see it.

Check what each machine actually loads

The repository shows what a team committed. The machine shows what Claude Code will load. Run these checks in each project folder that matters.

claude mcp list
claude mcp get <server-name>

Run claude mcp list from the project folder. It lists all configured servers with a health status: ✔ Connected, ! Needs authentication or ✘ Failed to connect. A failed status means Claude Code could not connect to the server. It does not mean the list command failed.
Run claude mcp get <server-name> for any server you did not expect, to see where it is configured.
Read the approval states. A project server you have not approved shows ⏸ Pending approval.
Remove anything that should not run with claude mcp remove <server-name>.

Method	Finds	Misses
Repository search for `.mcp.json`	Project-scoped servers that were committed	Local and user scope, and anything not committed
`claude mcp list` on each machine	Every server that machine’s Claude Code has configured	Machines and projects you never check
Pod and image listing in clusters	Workloads running in the cluster	Servers running on laptops

Find MCP servers running in a cluster

The Kubernetes docs I checked do not define a convention for marking an MCP server, so this post does not invent one. An MCP server in a cluster is a workload like any other. Discovery means listing the workloads, reading their images, and checking those images against what you approved. The Pod page describes a Pod as “a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers.”

List pods and their images

List pods in every namespace. The quick reference gives -A as the short form of --all-namespaces.

kubectl get pods --all-namespaces
kubectl get pods -A

Print the image of every container in every pod. The image is the field to compare against your approved list.

kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'

For a single namespace, print the pod name next to its images. Replace default with the namespace you are checking.

kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"

An image name can hide what runs inside it. The command above prints only the image, so a server started from a general-purpose image shows up as that image and nothing more. Check the pod name and the namespace before you decide what it is.

Group workloads with labels

Labels can help you sort the results. The Labels page defines them as “key/value pairs that are attached to objects such as Pods,” and says they “can be used to organize and to select subsets of objects.” A label selector is written as comma-separated requirements, such as environment=production,tier!=frontend. The commas act as AND. The docs also warn that there is no logical OR operator in either selector style, so you need one selector per group.

Labels only help if your team applies them. Nothing in the Kubernetes docs marks a pod as an MCP server, so a label such as the one your team chooses is a local convention, and it applies only to the workloads that carry it.

Shadow MCP servers: what the search misses

A shadow MCP server is one your security or platform team does not know about. The gaps are structural, not a matter of effort. Local and user-scoped servers sit in ~/.claude.json outside any repository. Stdio servers run as local processes, so a cluster listing never sees them. Project servers can load in claude -p runs without a prompt.

A short checklist covers the three places to look:

For each repository, is there a committed .mcp.json, and does every entry match an approved url or command?
For each machine that runs Claude Code, does claude mcp list show a server that is not in that repository’s file?
For each cluster, does any pod run an image that is not on your approved list?

A “no” on the first question and a “yes” on the second is the usual shadow case: a developer added a server for themselves. Neither search can prove that nothing runs, so pair these checks with a record of what the agents actually call. The audit post on MCP tool calls covers that side.

To control which servers load once you have found them, see how to restrict which MCP servers Claude Code can use. For the wider picture, start with MCP security.

Frequently asked questions

Where does Claude Code store MCP server configuration?

Claude Code has three scopes. Local scope is the default, and it stores the server under the project's path in ~/.claude.json. User scope also uses ~/.claude.json, and it applies to all of your projects. Project scope stores the server in a .mcp.json file at the project root, which a team can commit to version control.

Why doesn't a repository search find every MCP server?

Local and user-scoped servers live in ~/.claude.json on the developer's machine, not in the repository. A search of repositories only finds project-scoped servers in committed .mcp.json files. To see the full set on one machine, run claude mcp list in each project folder.

How do you find an MCP server running in a Kubernetes cluster?

List the pods in every namespace and read the image of each container. The Kubernetes docs define a pod as a group of one or more containers and do not define a label or image name for MCP servers. Any label your team applies to MCP workloads is a convention you set yourself, so check it against the images you approved.

What does pending approval mean for a project MCP server?

Claude Code asks for approval in interactive sessions before it uses project-scoped servers from a .mcp.json file. Until someone approves, claude mcp list shows the server as pending approval. In claude -p runs and Agent SDK sessions, Claude Code cannot show that prompt and loads those servers without asking.