# How do I control which MCP servers developers' agents use?

> Find the MCP servers agents can reach, allowlist them with each client's own settings, scan their definitions, and block unapproved ones at the call.

An MCP server gives an agent new tools, and often new credentials and new places to send data. Controlling them is four jobs: know what is configured, decide what is allowed, check what each server says about itself, and stop the ones you have not approved.

## Know what is configured

Each client keeps its own list, and most read one per user and one per repository:

| Client | Where servers are configured |
|---|---|
| Claude Code | `~/.claude.json` for the user and per project, and a repository's `.mcp.json` |
| Cursor | `~/.cursor/mcp.json`, and a repository's `.cursor/mcp.json` |
| Codex | `~/.codex/config.toml` |

A repository's own file matters: cloning a repository can bring a server with it. Claude Code asks before it starts a server from a project's `.mcp.json`.

## Decide what is allowed

Claude Code's managed settings can restrict which servers users may configure, with `allowedMcpServers` and `deniedMcpServers`, and a `managed-mcp.json` file can deploy a fixed set that users cannot change. Deploy both through your device management; see [How do I roll out coding-agent security with Jamf, Intune or Kandji?](/guides/mdm-rollout) Other clients have their own admin controls; check each one's documentation.

## Check what each server says

- **Pin versions.** A server started with `npx some-server` or `uvx some-server` without a version runs whatever was published last.
- **Read the tool descriptions.** The model reads them as instructions. A description can carry an injection, and it can change after you approved the server.
- **Prefer HTTPS for remote servers,** and look at what credentials each one is given.
- **Scan definitions.** Open-source scanners such as mcp-scan, from Invariant Labs (now part of Snyk), check server definitions for known problems.

## What that leaves open

- A configuration file says what could run, not what did. You learn which servers are actually used only by watching calls.
- Each client and each machine is configured separately, and a server added in one repository is easy to miss.
- A definition can change after it was reviewed, and nothing in the client tells you.
- Allowlists in managed settings cover the clients that have them, and only on machines where they are deployed.

## Where Golem fits

**An inventory built from calls.** **Watch → Security Inventory → MCP servers** lists every server an agent actually called, with its definition, from what passed through Golem rather than from what anyone registered. Each server can be decided **Allow**, **Allow · read-only**, **Alert** or **Block**. A server whose definition changes after you decided it reappears under **Changed since decided**.

**First use of an unapproved server.** Under **Security Inventory → Settings**, **Unreviewed MCP servers** is **Allow** (the default), **Alert on first use** or **Block**. A blocked call tells the agent that the server is not approved and where an admin approves it, with a decision id. Deciding **Allow** in the inventory is the approval. See [Shadow AI](/coverage#shadow-ai).

**Config scan.** Every 30 minutes the Golem agent reads the MCP servers configured for Claude Code (global, per project and each repository's `.mcp.json`), Cursor, Windsurf, Gemini CLI and Claude Desktop. It alerts on a server that pipes a download into a shell or a remote server over plain http, and records servers run unpinned through `npx` or `uvx`. See [What agents load](/coverage#what-agents-load).

**Rules on servers and tools.** A [rule](/rules) can read `entry.mcp_server_id`, `entry.tool_name` and `entry.tool_description_changed`, and hold or refuse a call on any of them.

**Two places to stop a call.** Your MCP servers can stay in each client's own configuration, where Golem sees and judges their calls through the client's hooks. Or you can route a server through Golem's MCP gateway, which puts Golem in the connection: a refused call never reaches the server, even if a client skipped its hook, and the client gets JSON-RPC error `-32050`. See [MCP servers: hook or gateway](/coverage#mcp-servers-hook-or-gateway).

## What Golem does not do

- It never edits a client's MCP configuration. Blocking happens at the call; removing the entry is for the developer or your device management.
- Golem's own servers (`golem-witness`, `golem-context`) and clients' built-in tools are never treated as unapproved.
- A server that is called through a client Golem is not wired into is not seen. The client still appears under [Shadow AI](/coverage#shadow-ai) as not wired.
- The scan judges each definition on its own. Golem has no reputation catalogue of public MCP servers.

## Read next

- [Coverage](/coverage): the Security Inventory and Shadow AI
- [Block, hold and contain](/response#over-mcp): what a refusal on the MCP path looks like
- [Limits](/limits)