How to allowlist MCP servers in Cursor

To allowlist MCP servers in Cursor, an Enterprise admin adds each approved server in the team dashboard, under MCP Configuration. Local stdio servers are approved by command pattern, and remote servers by URL pattern. Tool allowlists and per-server network settings narrow what each approved server can do. Allowlisting approves a configuration. It does not install the server.

What the Cursor allowlist controls

The MCP allowlist decides which servers and tools a team may run. Cursor documents it as an enterprise control, set in the team dashboard, and the docs describe no equivalent for other plans. It governs what runs. It does not decide what gets installed, so a developer still has to add the server to their own Cursor settings after you approve it.

If the whole team needs the same server, use a team marketplace. Admins can link an existing standalone Team MCP server to the Default marketplace, and teammates then install and configure it from Customize. Linking a server does not install or enable it for everyone, so plan that step separately.

Check that your plan includes it

The MCP Configuration page is marked Enterprise only. If your team dashboard does not show it, you cannot set this allowlist yourself. The steps below cover only the dashboard procedure. Confirm with your Cursor account team which controls your plan includes before you build a rollout around the steps below.

Collect the command or URL for each server

Checked against Cursor’s MCP and enterprise docs as of 2026-11-03. Those pages do not state a Cursor version.

Each entry matches what Cursor will run, so start from the configuration file. Project servers live in .cursor/mcp.json inside the project, and global servers live in ~/.cursor/mcp.json in your home directory. Copy the exact command and args, or the exact url, from there.

{
  "mcpServers": {
    "my-tool": {
      "command": "npx",
      "args": ["-y", "@acme/mcp-tool@latest"]
    }
  }
}

{
  "mcpServers": {
    "acme-tools": {
      "url": "https://mcp.acme.com/sse"
    }
  }
}

For a local server, the match uses the full command string: the command plus every argument, joined with spaces. The docs point out that the shell may resolve npx to a full path, such as /usr/local/bin/npx or /opt/homebrew/bin/npx, and that changes the string Cursor compares. Remote servers match on the URL alone.

Add a command or URL entry for each server

Choose the entry type

Each approved server gets one entry, and the entry type follows its transport. The two types have different match rules and different network controls.

Server type	Entry type	What it matches	Network control
Local stdio (`command` and `args`)	Command entry	The full command string	The server’s own network mode
Remote HTTP or SSE (`url`)	URL entry	The URL pattern	Restricted to the URL entry pattern

Add the entries

Open MCP Configuration in the team dashboard.
Add a command entry for each local stdio server, and a URL entry for each remote server.
Write each pattern from the full command string or the full URL. Add * where the install path or version can vary.
Set the Tools field and the network policy for that server before you add the next one.
Repeat for every server on the list, then check a developer machine as described below.

Write patterns that match

Every allowlist entry supports *, which matches any sequence of characters. Leading wildcards let one entry cover a server wherever it is installed. The examples below come from the docs, and the same rules apply to your own servers.

Allowlist entry	Matches
`*npx -y @acme/mcp-tool@latest`	`npx` at any path, with these exact arguments
`/usr/local/bin/npx -y @acme/mcp-tool@latest`	Only this exact path
`npx -y @acme/`	Any `@acme`-scoped MCP package
`python /scripts/mcp-server.py*`	A Python server at any matching path, with any trailing arguments
`https://mcp.acme.com/sse`	This exact URL
`https://.acme.com/`	Any subdomain and path under `acme.com`
`https://mcp.acme.com/*`	Any path on this host

Keep patterns as narrow as the server allows. A pattern such as https://*.acme.com/* admits every subdomain of acme.com, not one host, so review each wildcard the way you would review a firewall rule.

Limit tools and network access

Restrict the tools each server can run

Cursor asks for approval before using MCP tools by default. A tool allowlist restricts which tools from an approved server can run automatically. For each server, list the allowed tools in its Tools field. Leave the field empty to allow every tool that server provides.

Start with a short list for any server that can change data. Widen the list only after you have seen the tools in use on a developer machine.

Set the network mode for local servers

Local command-based servers run with one of four network modes. The mode is set per server, so one server can be locked down while another has full access.

Allow all: no egress restrictions on outbound network access.
Allowlist: only listed destinations are reachable. The docs do not say where that destination list is set.
Deny all: the server runs with no outbound network access.
No sandbox: the server runs without command or network sandboxing.

Remote URL servers are restricted to their configured URL entry pattern, so the URL entry also limits where they can connect. That controls where Cursor connects. It does not control where the remote service sends traffic once it runs on its own host.

Confirm the result on a developer machine

Allowlisting is only useful if the server behaves as the entry says. Check it on a machine that uses the same team settings.

Open the Output panel. Press Cmd+Shift+U on macOS or Ctrl+Shift+U on Windows and Linux.
Select “MCP Logs”.
Find the initialization messages for the approved server. Look for connection errors, authentication issues or server crashes.
Repeat with a server that is not on the list, and confirm that it does not connect.

If an approved server fails, compare the command or URL in the log with the entry you wrote. Most failures come from a path or version that changed after the entry was made.

Gotchas the docs call out

Allowlisting does not install anything. Teammates still need the server in their own settings, or it has to come from a team marketplace.
Local matches use the full command string. If you change an argument, such as a package version, the old entry stops matching. Update the entry at the same time.
Wildcards are broad. A wildcard URL pattern such as https://mcp.acme.com/* covers every path on that host. An exact URL covers only that URL, so check which form you are saving.

Enforcing this across coding agents

The Cursor allowlist covers Cursor only. Claude Code and GitHub Copilot have their own MCP controls, so a team that uses more than one tool needs a rule for each. Our posts on restricting MCP servers in Claude Code and controlling MCP servers in GitHub Copilot cover those settings. Keep one written list of approved servers, with each command or URL, an owner and the tools each server may run, and check every tool’s settings against that list.

For the wider program, read MCP security and how to audit MCP tool calls. For the product, see AIControls.

Sources checked

Cursor: MCP, fetched 2026-11-03
Cursor: model and integration management (MCP Allowlist), fetched 2026-11-03
Cursor: MCP help page (logs), fetched 2026-11-03

Cursor’s pages do not state a version or publication date.

Frequently asked questions

Do I need an Enterprise plan to allowlist MCP servers in Cursor?

The docs place the MCP allowlist in the team dashboard, under MCP Configuration, and mark that page Enterprise only. Enterprise admins set it. The docs do not describe an equivalent admin allowlist for other plans, so if your team dashboard does not show MCP Configuration, you cannot set this list yourself. Ask your Cursor account team which controls your plan includes before you plan a rollout around this procedure.

Does adding a server to the Cursor allowlist install it for developers?

No. Allowlisting approves a configuration, and the docs say it does not distribute or install the server. Developers still configure the server in their own Cursor settings. To give the whole team the same server, add it to a team marketplace. Admins can link an existing standalone Team MCP server to the Default marketplace, and teammates then install and configure it from Customize.

What is the difference between a command entry and a URL entry?

A command entry approves a local stdio server by its command pattern. The match uses the full command string, which is the command plus every argument joined with spaces. A URL entry approves a remote HTTP or SSE server by its URL pattern. Both support the * wildcard. Tool allowlists and network settings then narrow what each approved server can do, and they are set per server.

How do I stop an approved MCP server from running a tool I have not reviewed?

List only the reviewed tools in that server's Tools field. The docs say a tool allowlist restricts which tools from an approved server can run automatically, and an empty field allows every tool from that server. Cursor also asks for approval before using MCP tools by default. Re-check the list after each server update, since an empty field allows whatever tools the server exposes.

Where do I see why a Cursor MCP server did not connect?

Open the Output panel with Cmd+Shift+U on macOS or Ctrl+Shift+U on Windows and Linux, then select MCP Logs. The docs say the logs show server initialization, tool calls and error messages, including connection errors, authentication issues and crashes. Read them on the developer machine where the server failed, since that is where the error occurred.