How to Stop Claude Code from Asking Before Every MCP Tool Call

When Claude Code asks before using an MCP tool, the prompt is usually controlled by a permission rule. MCP, or Model Context Protocol, lets Claude Code connect to external tools such as services and integrations. To approve a trusted tool automatically, add its full name to permissions.allow in a Claude Code settings file.

This rule handles prompts before regular tool calls. It does not override safeguards such as a tool that requires human interaction or an organization’s approval policy. Identify what Claude Code is asking you to approve, then use the matching fix.

Allow a specific MCP tool

Add the tool’s full name to the allow array in a settings file:

{
  "permissions": {
    "allow": [
      "mcp__your-server__your-tool"
    ]
  }
}

Replace the example with the exact tool name Claude Code displays. Run /mcp in your session to inspect connected servers and their tools. Names commonly follow the pattern mcp__<server>__<tool>. Plugin-provided tools can have longer names, so copy the full displayed name rather than guessing. The MCP documentation describes tool naming and server setup.

If you trust every tool from one server, use a wildcard (*) to allow all of that server’s tools:

{
  "permissions": {
    "allow": [
      "mcp__your-server__*"
    ]
  }
}

This also covers tools the server adds later. Use the literal server name in the rule: the broad pattern mcp__* is not a valid allow rule, according to the permission rule documentation.

Choose where to save the rule

Claude Code reads settings from files that apply at different levels. Put the rule in ~/.claude/settings.json to use it across projects on your machine. Put it in .claude/settings.local.json for a personal setting in one project, or in .claude/settings.json to share it with that project. The settings documentation explains these scopes and how project trust affects settings.

Settings files require valid JSON, so remove comments and trailing commas. After saving the change, run /status to check whether Claude Code loaded the settings, then run /permissions to see the active rules and where they came from. The change applies to the next tool call.

Check which prompt you are seeing

A prompt to approve an MCP server is different from a prompt to approve each tool call. A project-scoped server defined in .mcp.json has a separate approval step. Review and approve the server when Claude Code asks; if the project is still untrusted, project settings may not take effect until you trust the workspace.

If Claude Code keeps asking about a tool call after you add an allow rule, check whether another permission rule matches. Claude Code evaluates rules in this order: deny, then ask, then allow. A matching ask rule still prompts even when an allow rule also matches, and an allow rule cannot override a matching deny rule. Use /permissions to inspect the rules and their sources.

Some prompts come from safeguards that local settings cannot override. An MCP server can mark a tool as requiring human interaction, which makes Claude Code ask before every call and removes the “don’t ask again” option. An organization can also configure a connector tool to ask for approval on each call. In either case, contact the server maintainer or your administrator rather than adding broader local permissions. The MCP documentation describes these exceptions.

Avoid using a broad permission mode as a shortcut

A mode such as dontAsk suppresses prompts by denying actions that would otherwise require approval, so Claude Code can deny the MCP call instead of running it. acceptEdits focuses on accepting file edits and does not generally approve MCP tools. bypassPermissions skips most permission prompts, but it does not override every safeguard. Anthropic recommends using it only in an isolated environment, such as a container or virtual machine. For a trusted integration, a narrowly scoped permissions.allow rule is the more targeted fix.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com