MCP allowlist: limit which tools an agent can call

An MCP allowlist is a list of what an AI agent is permitted to use, with everything else denied by default. People mean two different things by it: a list of approved MCP servers that may be connected at all, or a list of approved tools within a server. You usually want both. This guide covers where each kind of list lives, what the major clients support today, where client-side lists fall short, and how to enforce tool allowlists at a gateway.

Two kinds of MCP allowlist

Server allowlists answer "which MCP servers may run here?" They're an organization control. An admin publishes approved server URLs or commands, and the client refuses to load anything else. This protects against someone connecting an unvetted server, whether a typo-squatted npm package or a remote endpoint nobody reviewed.

Tool allowlists answer "which tools from an approved server may this agent call?" A GitHub or Linear server can expose dozens of tools, from harmless searches to deleting repositories. A tool allowlist keeps an agent to the handful its job needs.

The two layers fail differently. A server allowlist alone still lets an agent call every tool on an approved server. A tool allowlist alone doesn't stop someone adding a new server alongside it. Most teams end up with both.

Client-side options

Every major MCP client has some form of allowlisting. Syntax changes often, so the summaries below link to each vendor's current documentation; check there before copying a config.

Claude Code

Claude Code has both layers.

For tools, permission rules in settings.json use the form mcp__<server>__<tool>. Rules go under allow, ask or deny, and Claude Code evaluates them in that order: deny, then ask, then allow. mcp__github or mcp__github__* matches every tool from a server you named github. Allow rules accept a wildcard only after a literal server prefix, such as mcp__github__get_*, so a bare mcp__* allow rule is ignored.

{
  "permissions": {
    "allow": ["mcp__github__get_*", "mcp__github__search_issues"],
    "deny": ["mcp__github__delete_repository"]
  }
}

The tool names here are illustrative; use the names your server actually exposes. Rules for MCP tools can't match arguments in settings files. Claude Code skips any mcp__ rule written with parentheses.

For servers, administrators can set allowedMcpServers and deniedMcpServers in managed settings, matching by serverUrl, serverCommand or serverName. Setting allowManagedMcpServersOnly: true stops users broadening the list in their own settings. The managed MCP documentation warns that serverName entries aren't a security control, because users choose server names; use URL or command entries for enforcement. Organizations using claude.ai connectors can also set individual connector tools to ask or blocked.

The Claude Code permissions guide goes further into modes, file locations and precedence.

Cursor

Cursor asks for approval before running MCP tools by default, and MCP tools follow the same run modes as terminal commands. In Auto-review mode, allowlisted MCP tools run immediately and other calls go through Cursor's classifier. Individual users can enable or disable whole servers from Customize.

Enterprise admins can set server allowlists under Team Settings > MCP Configuration, with command entries for local servers and URL entries for remote ones. Each approved server can carry a tool allowlist that restricts which tools run automatically; leaving it empty allows all tools from that server.

Codex CLI

Codex configures each server in a [mcp_servers.<name>] table in ~/.codex/config.toml. OpenAI's MCP documentation lists enabled_tools as the tool allowlist and disabled_tools as a deny list applied after it. Approval behavior is set per server with default_tools_approval_mode (auto, prompt, writes or approve) and per tool with tools.<tool>.approval_mode.

[mcp_servers.tracker]
url = "https://mcp.example.com/mcp"
enabled_tools = ["search_issues", "get_issue", "create_issue"]
default_tools_approval_mode = "prompt"

The writes mode prompts for tools that aren't marked read-only. That depends on the server's own annotations, which the MCP specification says clients should treat as untrusted unless the server is trusted.

VS Code and GitHub Copilot

In VS Code you can select or deselect individual tools and whole MCP servers in the tools picker. Enabling a tool makes it available; it doesn't bypass approval prompts. A chat request can have at most 128 tools enabled, which is a practical reason to trim the list.

For organizations, GitHub supports enterprise MCP server allowlists through allowedMcpServers and deniedMcpServers in a managed settings file, matching by name, URL or command. Deny rules take precedence.

Where client-side lists fall short

Configure client allowlists, but know that they're limited by where they live.

• They're per machine and per app. A rule in one developer's Claude Code settings does nothing for their Cursor install, or for a teammate. Five apps across ten laptops means fifty configs to keep in sync.
• They drift. Someone adds a tool to unblock a task and never removes it. Project files get forked. Without a central view, nobody knows what the effective list is.
• Users can usually edit them. Unless your organization enforces managed settings, the person running the agent can change their own rules. That's fine for convenience, less fine for policy.
• The credentials stay local. The upstream token still sits in the developer's config. A tool allowlist in the client doesn't stop someone using that token directly, or from another app.
• There's no shared audit trail. Each client logs locally, if at all, so answering "which agents called delete_* last week?" means asking everyone.

Managed settings fix some of this for a single client, so use them if your organization already deploys them. They're still specific to each vendor's app.

Gateway-side allowlisting with Toolstile

An MCP gateway moves the allowlist to the place every request passes through. In Toolstile, server connections live in a workspace, each AI app signs in as its own agent, and the agent's rules decide what it can reach. The same rules apply whichever app the agent runs in.

How the rules work:

• Each agent starts with nothing. Signing in from Claude Code or Cursor doesn't grant any tools. You grant access per agent and per connection.
• Allows use exact names. Tool and prompt entries match exact names; resources match a URI or URI template. Enter the names your connection actually exposes, as shown in Access.
• Full access includes future tools. "Everything, including ones added later" is convenient, but a tool the server ships next month becomes available without review. If you want to review new tools first, keep full access off and list the tools you allow.
• Blocks win. A block in any applicable source denies the tool, even if another grant or a reusable policy allows everything. Removing an allow from one place may leave another allow active, so use a block when you mean "never".
• Require approval for risky tools. Mark a tool Require approval and each call waits for review. It ranks between the two: a block beats it, and it beats any allow or full access. The approval covers that exact call with those exact arguments, and approvers are workspace owners and admins (or the connection owner in a personal workspace).
• Discovery is filtered. An agent's tool list contains only what it may use, and every call is checked again, so a remembered tool name doesn't get through.

Toolstile's rules don't replace the upstream account's permissions. If the connected account can't do something, no allow rule changes that. The permissions docs cover policies, devices and revocation.

A worked example

A team connects an issue tracker to a Toolstile workspace. The server exposes search_issues, get_issue, create_issue, update_issue, add_comment and delete_issue. These names are illustrative.

Three agents use it:

In practice:

1. The support agent lists tools and sees three of them. When it tries to comment on a ticket, it gets back an approval-required result with a review link. An admin opens Approvals, checks the exact comment text and approves once. The agent retries the same call and it goes through. If it changes the text, it needs a new approval.
2. The coding agent can work through issues without prompts from Toolstile. Its developer can still keep Claude Code's own ask rules for local confirmation.
3. Six weeks later the server adds bulk_close_issues. None of the agents can see it, because none of them has full access. Someone reviews the tool, then decides who, if anyone, gets it.
4. A reusable policy later grants the coding agent full access to the tracker. delete_issue stays blocked, because the direct block wins.

The explicit delete_issue block looks redundant when the allows are explicit. It earns its place in step 4, the day someone attaches a broader policy.

MCP allowlist checklist

• List the servers your organization approves, and enforce that list with managed settings in the clients that support it. Match by URL or command, not by user-chosen name.
• For each agent, write down the tools its job needs. Start from nothing and add, rather than starting from everything and removing.
• Prefer exact tool names over full access when new tools should be reviewed first.
• Block destructive tools explicitly, even when they aren't allowed, so a future broad policy can't expose them.
• Require approval for tools that send, publish, pay or delete when an agent genuinely needs them.
• Use least-privilege upstream accounts. An allowlist limits which tools run, not what the account behind them can do.
• Keep upstream credentials out of developer config files where you can.
• Review activity for denied calls and approval requests; they show where the list is too tight or an agent is misbehaving.
• Revisit the list when a server ships new tools or an agent's job changes.

To set this up in Toolstile, start with getting started, then open permissions for the rule details. Pricing lists which plans include reusable policies.