TL;DR: An MCP tool’s canonical name carries its server identity. That gives Claude Code a useful permission scope: a single rule can cover every tool from one server. It does not make an external tool intrinsically safe, though. In the usual manual-permission flow, a call without an applicable allow rule asks the user; a server can also mark a sensitive tool as requiring an explicit approval on every call.
The previous article ended at the point where a discovered MCP capability becomes a tool in Claude Code’s tool list. That raises the next question: once Claude can see a renamed MCP tool, may it simply invoke it?
The answer is shaped by the permission system. This article focuses on the MCP-specific part of that system: how a tool name becomes a policy boundary, why that boundary can be a whole server, and why server trust and per-call authorization remain separate decisions.
One rule can cover an entire server
A Claude Code MCP tool is named in the form:
mcp__<server>__<tool>
That name is more than display metadata. It preserves where the capability came from. For example, the tool name mcp__jira__create_issue says both what Claude wants to call and which server provides it. The MCP protocol itself asks a client to discover tools with tools/list; each tool definition has a unique name, a description, and an input schema. Claude Code adds the server-qualified name so that separately connected servers do not collapse into one flat, ambiguous namespace.
That structure gives permission rules a useful extra level of granularity. According to Claude Code’s current permission syntax:
{
"permissions": {
"allow": [
"mcp__jira__*"
]
}
}
The rule matches every tool exposed by the jira server. A rule such as mcp__jira__create_issue instead targets just that one tool. For a configured server with punctuation or spaces, Claude Code uses its normalized server segment in the tool name. A server supplied by a plugin uses a plugin-scoped server name.
This is particularly practical for a server that exposes a family of related operations. A Jira server might provide issue lookup, creation, comments, transitions, and project metadata. A team can decide that this specific integration is acceptable and express the policy once, rather than maintain an ever-growing list of individual tool names as the server evolves.
There is an important constraint: allow-rule wildcards are intentionally narrower than deny and ask wildcards. An allow rule needs the literal mcp__<server>__ prefix, so a broad entry such as mcp__* does not silently auto-approve every MCP tool from every server. The policy must name the particular configured server it trusts.
The name creates a policy boundary
The useful comparison is not “MCP tools versus safe built-in tools.” It is “a capability from a known server versus a capability from somewhere else.” Claude Code’s built-in tools can have tool-specific rules and, for some categories, additional action-specific handling. An MCP tool is an extension supplied by a server: it can query an API, edit a ticket, read a database, or trigger an operation outside the local project.
Its server-qualified name lets the client apply a consistent rule before issuing the tools/call request:
- The server advertises a tool through
tools/list. - Claude Code gives the exposed capability a full
mcp__<server>__<tool>name. - Permission policy checks that canonical name against deny, ask, and allow rules.
- Only an allowed call is sent to the server as
tools/call.
This is also why a server-wide rule is meaningful. It does not claim that all tools are harmless; it records a deliberate trust decision about the server namespace. An organization may allow all tools from an approved internal service, ask before calls to a staging service, and deny an unapproved server altogether.
The reverse works too. A deny or ask rule can use a full-name pattern such as mcp__* to govern MCP tools across servers. A policy can therefore make the default posture explicit rather than relying on the apparent friendliness of a tool’s description.
No rule should be mistaken for no decision
In Manual mode, Claude Code’s permission system normally presents an approval prompt for actions that require approval. MCP tool prompts are part of that flow, and the permission dialog lets the user approve or deny the proposed call. A matching allow rule can avoid routine prompts for the precise scope it names; a deny rule blocks the call.
That distinction matters when installing a new MCP server. Connecting a server, exposing its tools, and authorizing a particular action are related but different events. A server may be correctly configured and successfully connected while its tools still require approval according to the active policy.
The Model Context Protocol makes the same safety principle explicit: implementations should keep a human able to deny tool invocations, show which tools are exposed, and present confirmations for operations. The protocol defines how a server advertises and receives tool calls; it does not declare that a given remote operation is safe.
Claude Code also supports a stronger signal from the server itself. An MCP server author can set:
{
"_meta": {
"anthropic/requiresUserInteraction": true
}
}
on an individual tools/list entry. Claude Code then requires an explicit approval on every call to that tool, even if a matching allow rule exists or a permissive mode is active. This is appropriate for actions where the human confirmation is itself the point, such as granting access to a protected resource.
Trust is layered, not inherited
The server-level wildcard is a convenience, not an automatic security proof. MCP servers may reach external services and handle data outside Claude Code’s local runtime. Claude Code’s MCP documentation therefore advises users to verify that they trust each server before connecting it, especially when a server can fetch external content and expose prompt-injection risk.
A sound policy separates several questions:
| Question | Example decision |
|---|---|
| Should this server connect? | Approve a known internal Jira server; reject an unknown one. |
| Should Claude see this capability? | Deny a particular tool or all tools from a server. |
| Should this call run now? | Ask for approval, or allow a narrowly defined trusted scope. |
| Must a person always confirm? | Mark a sensitive server tool with requiresUserInteraction. |
This layered model is more durable than trying to infer safety from a tool name or natural-language description. A permission rule makes the intended boundary visible, reviewable, and shareable through settings. The server still owns the implementation; the client still owns the decision to invoke it.
What to remember
MCP tool names encode provenance, and that provenance becomes a practical authorization boundary. Use a full tool name when one operation deserves its own policy. Use mcp__<server>__* when a team has consciously chosen to trust a particular server’s whole tool family. Avoid broad allow rules that erase the distinction between servers.
Most importantly, do not equate discovery with authorization. Seeing a tool in the list means Claude Code knows how to call it. A permission rule and, when appropriate, a human approval determine whether it should call it now.
The next article follows the other gate that can prevent a server from becoming usable: authentication. We will trace how a server moves from “needs authentication” to an active connection, including the browser-based authorization step and how credentials can be reused across servers.
Top comments (0)