How to Control Which MCP Servers Developers Add to Their Coding Agents

Treat MCP servers like any other third-party dependency. Find out which ones are already in use, review them, and publish an approved list with pinned versions. Enforce the list in each agent's managed settings and underneath every agent. Watch approved servers for changes in behavior, and give developers a fast way to request new ones. Agent settings handle part of this. Qpoint covers the rest: every agent, what each server actually does, and a record of it.

Why unreviewed MCP servers are a risk

• A local MCP server is a program on the laptop. It runs with the developer's access to files, credentials, and the network. A server added as npx -y some-server downloads and runs whatever version is newest, every time it starts.
• A remote MCP server receives whatever the agent sends it, including code, tickets, and customer data.
• Servers can steer the agent. Tool descriptions and responses go straight into the model's context, so a bad server can tell the agent what to do next.
• Adding one takes a single line in a config file, so nobody reviews it.

Step 1: Find what's already in use

Start by finding out what developers already depend on. Blocking first breaks workflows you didn't know existed.

• Config files. Each agent keeps its MCP servers in its own files: ~/.claude.json and a project's .mcp.json for Claude Code, ~/.cursor/mcp.json and .cursor/mcp.json for Cursor, .vscode/mcp.json for VS Code, and ~/.codex/config.toml for Codex. A script pushed through MDM can collect these. It shows what is configured, not what runs, and it misses agents that keep config somewhere else.
• Agent telemetry. Claude Code can export which MCP servers and tools are used through OpenTelemetry. Other agents vary.
• Qpoint. Deploy to a pilot group in observe mode. Every agent and MCP server shows up as it starts, local or remote, with the user and host, regardless of where its config lives.

Step 2: Review each server

For each server in use or requested, check:

• Publisher. Is it the official server from the service's own vendor, or a personal repo?
• Source and upkeep. Is the source public, maintained, and owned by more than one person?
• Remote or local. Official remote servers run by the vendor are easier to control: a fixed URL and per-user sign-in. Local servers run code on the laptop.
• Version. npx -y package or uvx package without a version runs the latest release on every start. Approve a specific version and review updates.
• Tools. Which tools are read-only and which can write or delete? Decide which ones agents should be able to call.
• What it touches. Which files and hosts does it access, and which credentials does it need? Run it with a pilot group and look.
• Credentials. Prefer per-user sign-in over a shared API token in an environment variable.

The outcome for each server is approved (with a pinned version and allowed tools), approved for a pilot group, or not approved.

Step 3: Publish the approved list

Keep one list, owned by security or platform engineering. For each server, record the URL or pinned command, the allowed tools, who can use it, and an owner. Put it where developers will find it, with the install command for each agent.

Step 4: Enforce it in each agent

Most major coding agents now let admins push an MCP allowlist to developer machines:

• Claude Code: managed-mcp.json for a fixed set, or allowedMcpServers with allowManagedMcpServersOnly in managed settings.
• GitHub Copilot: allowedMcpServers in the enterprise managed-settings.json, enforced in the Copilot app, Copilot CLI, and VS Code.
• Codex: approved servers in requirements.toml, matched on name and command or URL.
• Cursor: an allowlist by command or URL in the Enterprise team dashboard.

Match servers by URL or by exact command, not by name. A name is a label anyone can give any server. Matching the exact command also pins the version. In Claude Code managed settings, that looks like this:

json

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverCommand": ["npx", "-y", "@acme/[email protected]"] }
  ]
}

For a comparison of these settings and what each one misses, see Tools to Set an Approved List of AI Agents and MCP Servers Across All Your Endpoints.

Step 5: Enforce it underneath every agent

Agent settings leave gaps. They only exist in agents that ship them, each agent needs its own list, and a developer can install a new agent that has none. Qpoint runs on each machine between the agents and the operating system, so one list applies to all of them:

• One approved list for every agent. Claude Code, Cursor, Codex, open source agents, and custom agents get the same check on every connection.
• Local and remote servers. A local MCP server is a command the agent starts, and a remote one is a network connection, so Qpoint sees both however the agent was configured.
• Unapproved servers are refused at connection. Individual tools on an approved server can be blocked while the rest stay available.
• Unapproved agents are flagged the moment they start, with the user and host.
• Rollout without touching agent config. Policies are staged and versioned like code, pushed to a pilot group first and then the fleet.

See Qpoint Govern for the full set of policies.

Step 6: Keep watching approved servers

A server that was safe when you reviewed it can change with an update, or be compromised upstream. Pinning versions helps, but what matters is what the server does.

Qpoint records each server's activity, including the files it reads and the hosts it calls, tied to the agent, session, and user. An MCP server that starts reading the home directory or calling an unknown host is stopped at that action, and the violation goes to your SIEM. Re-review a server whenever you approve a new version. More on blocking is on the Qpoint Secure page.

Step 7: Give developers a fast way to ask

• Publish how to request a server, what the review checks, and how long it takes. Aim for same-day decisions on official vendor servers.
• Use the usage data from step 1 to decide what to review first.
• Tell developers when a server is blocked and why. In some agents, a blocked server just disappears from the list with no message.

Common mistakes

• Matching servers by name. Anyone can name a server github.
• Approving unpinned servers. npx -y without a version means the approved code changes without review.
• Blocking before you know what's in use.
• Treating approval as permanent.
• Assuming the MCP list limits what the agent can reach. An agent without an approved Jira server can still call the Jira API from a script. Covering that means checking what the agent and its processes actually do on the machine.

Frequently asked questions

Do remote MCP servers need review too? Yes. They don't run code on the laptop, but the agent sends them data and they put tool descriptions into the model's context. Review the publisher, the tools, and how users authenticate.

Can we allow a server but block some of its tools? In some agents, yes. Cursor lets admins limit tools per server. With Qpoint, individual tools on an approved server can be blocked for every agent.

What about MCP servers that come bundled with plugins or extensions? They count. In Claude Code, the allowlist also applies to servers that plugins add. Qpoint sees them the same way as any other server, because it looks at what starts and what connects, not at config files.

Does Qpoint replace the agents' own settings? No. Turn on managed MCP settings where agents have them. Qpoint covers every agent the same way and checks what servers actually do.

Does this work on CI runners and in containers? Yes. The same Qpoint binary runs on macOS, Windows, and Linux laptops and on Kubernetes, containers, VMs, and CI runners. See the endpoints page for laptop rollout.

See it on your agents

Book a demo and we'll show you every MCP server your agents connect to, an unapproved one refused at connection, and how the approved list rolls out to your fleet.