In Claude Code, an MCP tool is named with the prefix mcp, then the server name, then the tool name, joined by double underscores. You can allow, ask or deny a whole server, one tool, or a family of tools. Rules are checked deny first, then ask, then allow, and the first match decides.
Naming an MCP tool
Anthropic's permissions page gives these forms, using a server called puppeteer:
- mcp__puppeteer matches any tool from that server.
- mcp__puppeteer__* uses the wildcard form and also matches all of its tools.
- mcp__puppeteer__puppeteer_navigate matches one specific tool.
Characters such as dots or spaces in a server name become underscores. A server you named my.server is written as mcp__my_server__*. Tools fetched from claude.ai connectors appear as mcp__claude_ai_ followed by the server and tool.
Wildcards have limits
Deny and ask rules accept globs in the tool name position. A deny of mcp__* removes every MCP tool across all servers from Claude's context.
Allow rules are stricter. Globs are accepted only after a literal mcp__server__ prefix, and the server part must be glob-free. So mcp__github__get_* is valid, and a bare mcp__* allow is skipped with a warning and approves nothing. That asymmetry is deliberate: broad denial is safe, broad approval is not.
Evaluation order
Rules are evaluated deny, then ask, then allow. An allow rule cannot carve an exception out of a deny rule. A matching ask rule prompts even when a more specific allow also matches. The same precedence holds across settings scopes, so a user level deny blocks a project level allow.
Matching arguments
Rules with parentheses for MCP tools are skipped when settings load, and Claude Code lists them as invalid. To match on a parameter of an MCP tool, the docs point to a deny rule passed through the disallowed tools command line option.
A sensible starting policy
- Allow read-only tools of servers you trust by exact name or a get prefix.
- Leave write tools on ask, so a person sees the arguments.
- Deny any server you do not recognise.
- Review the policy with the permissions command from time to time.
Pair rules with the guidance in MCP server permissions: a practical checklist. Safeguard's MCP Guardrail and agent identity features cover the same question at the organisation level, as described in MCP Guardrail and agent identity.
An example policy
Suppose you run a docs server and a ticketing server. Allow the docs server's read tools by exact name or a get prefix. Put every ticketing write tool on ask, so a person sees the arguments before a ticket changes. Deny any server you have not reviewed with the all-tools wildcard form scoped to that server. Because deny wins over allow, you can later add a broad deny for an incident response without editing every allow rule. Check the result with the permissions command, which shows what is in effect.
Quick check
Why did my broad allow rule do nothing?
Allow globs are only valid after a literal server prefix. A bare allow of every MCP tool is skipped.
Can a narrow allow override a broad deny?
No. Deny rules are evaluated first and the first match wins.
Sources
Last reviewed: 19 October 2026.
