Claude Code MCP Permission Rules: 2.1.299 Tested

In my claude -p tests on Claude Code 2.1.299 and 2.1.307, an allow rule of mcp__a covered only the MCP server named a. On 2.1.296 it also let the tools of a server named a__b run. A deny rule for mcp__a still blocked both servers.

I tested this with two stdio servers and three builds. Here is what ran, what did not, and the rule to write instead.

What You'll Learn

• What changed for MCP rules in 2.1.299, and what the docs say about names with __
• How I tested allow and deny rules with two look-alike servers
• Which rule forms behaved differently on 2.1.296, 2.1.299 and 2.1.307
• Which rules to write for a server whose name contains __
• What I did not test

What changed in 2.1.299

The Claude Code changelog lists three items about how MCP rules match server names under 2.1.299, dated October 14, 2026.¹

The first says allow rules now "reach only the server they name". Its example is that mcp__a no longer allows a server called a__b or a_. Anthropic's advice is to write mcp__<server>__* with the whole normalized name.

The second does the same for agent tools: lists. The third is a fix: deny and ask rules for mcp__<server> were not applying when the normalized server name contained a double underscore.

The ambiguity is in the names. An MCP tool is called mcp__<server>__<tool>, so mcp__reports__v2__summary could be tool v2__summary on server reports, or tool summary on server reports__v2. The permissions documentation says the bare mcp__reports__v2 and the shorter mcp__reports are both read as rules for a server named reports. As allow rules, neither matches the tools of reports__v2. As deny or ask rules, both also cover reports__v2.²

The docs and the changelog agree, but a bare server-name rule is easy to misread, so I ran the common forms against real servers.

How I tested it

I installed three builds from npm, each in its own folder: 2.1.296, 2.1.299 and 2.1.307. 2.1.296 was published on October 9, 2026. 2.1.299 followed on October 14 and 2.1.307 on October 21. 2.1.307 was the newest build when I ran the 216 main runs. 2.1.308 was published on October 22 at 04:19 UTC, after those runs, and I did not test it. A later check of 15 runs, described below, used the same three pinned builds. npm has no 2.1.297 or 2.1.298.³

The two servers are the same file started with different names. Server a has one tool, ping, so its full name is mcp__a__ping. Server a__b also has a tool ping, which gives mcp__a__b__ping. Both names start with mcp__a__, which is the point. Each tool appends a line to a log file when it runs, so the log shows what executed regardless of what the model said.

The server uses the MCP TypeScript SDK 1.32.1 and zod 4.6.7, the SDK's schema dependency.⁴

// server.mjs
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { appendFileSync } from "node:fs";

const [name, toolName] = process.argv.slice(2);
const s = new McpServer({ name, version: "1.0.0" });

s.registerTool(
  toolName,
  { description: `Ping tool of server ${name}. Returns a fixed string.`, inputSchema: {} },
  async () => {
    appendFileSync(process.env.PING_LOG, `${process.env.RUN_ID}\tserver=${name}\ttool=${toolName}\n`);
    return { content: [{ type: "text", text: `pong from ${name}` }] };
  }
);

await s.connect(new StdioServerTransport());

{
  "mcpServers": {
    "a": { "command": "node", "args": ["server.mjs", "a", "ping"] },
    "a__b": { "command": "node", "args": ["server.mjs", "a__b", "ping"] }
  }
}

Each run was a real claude -p call. The model was the haiku alias, which the JSON output reported as claude-haiku-5-5. I passed --strict-mcp-config so that only my two test servers came from my own MCP config, --setting-sources "" to skip user, project and local settings files, and one rule set per run. The prompt asked for both tools in order, even if the first was refused.

npm i @modelcontextprotocol/sdk@1.32.1 zod@4
npm i @anthropic-ai/claude-code@2.1.299   # one folder per build

PING_LOG=$PWD/ping.log RUN_ID=t1 npx claude -p \
  "Call the MCP tool mcp__a__ping and then the MCP tool mcp__a__b__ping, one after the other, even if the first one is refused. Then reply with exactly two lines: 'mcp__a__ping: ran' or 'mcp__a__ping: refused', and the same for mcp__a__b__ping." \
  --mcp-config mcp.json --strict-mcp-config --setting-sources "" \
  --model haiku --output-format json --allowedTools "mcp__a" < /dev/null

cat ping.log

For the other cases I changed only the rule flags: --allowedTools and --disallowedTools with comma-separated rules, or --settings pointing at a small JSON file for the settings-file case. The name-collision test used a second config file and a prompt that asked for one tool.

I ran 24 rule configurations, three runs per build each, 216 runs in all. This post reports 12 of them. The other 12 were seven early deny variants, three extra allow and settings-file controls, and two more name-collision variants. The early deny variants allowed mcp__a and mcp__a__b (one used mcp__a__*). None of these covers a__b on 2.1.299 and 2.1.307, so a refusal there could come from the missing allow rather than the deny rule. I redid five of them with an allow set of mcp__a__b__* and mcp__a__ping, and I report only the redo. One configuration also had nine invocations that failed because of a stray space in my case list. I overwrote those with a re-run.

Every case I report gave the same result three times out of three, except the name-collision test near the end. All runs were on October 22, 2026, on Linux x86_64. The test servers ran on Node.js 22.22.0.

In -p mode a call that no rule grants is refused and listed under permission_denials in the JSON. A tool blocked by a deny rule is different: it never appeared in permission_denials in my runs. In a separate 15-run check, I ran the five deny cases in the figure (the control, mcp__a__b, mcp__a, mcp__a__b__* and mcp__a__ping) once per build with --output-format stream-json --verbose. In every one of those runs the init message that lists the session's tools left out every tool that a deny rule blocked, and listed it when the deny rule did not apply. So in these runs a deny rule removed the tool from the session's tool list instead of refusing the call. The model's "refused" label does not say which of the two happened, a permission refusal or a missing tool. In 8 of the 11 runs of that check where a tool was missing from the list, the model still tried to call it and got a "No such tool available" error. The log file shows what ran, and the init list shows what the session offered. The sessions in that check also listed a claude-in-chrome server from my environment, and none of the rules here match its tools.

Allow rules

The figure below shows the main cases. Each cell is which server's tool ran, and bold cells differ between builds.

With mcp__a as the allow rule, 2.1.296 ran both tools. 2.1.299 and 2.1.307 ran only the tool of server a and refused the other one. A wildcard rule behaved the same: mcp__a__* matched a__b on 2.1.296 and did not on 2.1.299 or 2.1.307. Putting mcp__a under permissions.allow in a settings file passed with --settings gave the identical split, so the CLI flag and the file agree.

The rule mcp__a__b is the surprise. I expected it to allow server a__b. On all three builds it allowed neither tool. That matches the docs, which say a bare mcp__reports__v2 is read as a rule for a server named reports. Here that means server a, which has no tool b.

Two forms worked on every build for the server with the double underscore: mcp__a__b__* allowed a__b and refused a, and the exact name mcp__a__b__ping did the same. The changelog recommends the wildcard form, and the docs list both.

For an unattended script this has a practical edge. If your allow rule was mcp__a and you also run a server named a__b, that rule covered the tools of a__b on 2.1.296. On 2.1.299 and 2.1.307 the same call is refused in -p mode. Every run had both servers configured, so I did not test a config with only a__b. I also did not test an interactive session, where I would expect a permission prompt instead.

Deny rules

For the deny cases I report, I allowed both tools explicitly (mcp__a__b__* and mcp__a__ping), so any block comes from the deny rule. The control, a deny on a server that does not exist, left both tools running on all builds.

A deny on mcp__a__b is where the fix shows. On 2.1.296 it did nothing: both servers ran, including a__b, the one the rule was meant to stop. On 2.1.299 and 2.1.307 it blocked a__b and left the tool of server a running. This matches the changelog item about deny and ask rules.¹

A deny on mcp__a blocked both servers on all three builds, even though mcp__a__b__* was allowed. The docs describe this: as a deny rule, the short form also covers the look-alike.² It is the safe direction, but it means a deny written as mcp__a cannot leave a__b alone. I did not test a deny written as mcp__a__*.

A deny on mcp__a__b__* blocked only a__b. A deny on the exact tool mcp__a__ping blocked only the tool of server a and left a__b running. The docs suggest the same route: one rule per tool when you need to cover a without touching a similar name.² Server a has only one tool, so one rule was enough. I did not test a server with several tools.

Which rule to write

For servers you configured yourself, the name in the rule is the normalized name that appears in the tool names, with characters like . and spaces turned into _.² If the normalized name contains __ or ends in _, the docs say to use the wildcard form with the whole name.

When two servers produce the same tool name

I also tried a nastier setup: server a exposing a tool called b__ping and server a__b exposing ping. Both flatten to mcp__a__b__ping. I asked for that one tool, with an allow rule for that exact name, and the server that answered changed between runs on every build. On each build, a__b answered twice and a once in three runs. I cannot say why, and I make no claim about which server wins. The practical advice is simple: do not run servers whose names and tools flatten to the same string.

What I did not test

• Interactive sessions, where I would expect an ungranted tool to prompt rather than fail.
• Auto mode and its classifier. The same 2.1.299 changelog section also lists a fix for tools of an MCP server named constructor or toString asking for permission in auto mode and bypass permissions mode.¹ I did not test that.
• Ask rules. The changelog covers them, I only ran allow and deny.
• The agent tools: list change from the same changelog entry.
• Servers provided by plugins, rules from managed settings, and servers with a trailing underscore such as a_, which the changelog also names.
• Other models. I would not expect permission matching to depend on the model, but every run used haiku.
• Builds other than 2.1.296, 2.1.299 and 2.1.307. That includes 2.1.300 to 2.1.306 and 2.1.308. npm has no 2.1.297 or 2.1.298.

I also searched the changelog sections for 2.1.300 to 2.1.307 for the terms mcp__, allow rule, deny rule and permission rule, and read every MCP bullet in them. I found no other change to how MCP permission rules match.⁵ A quick audit, which I did not run as a test: list your servers with claude mcp list, apply the docs' normalization to each name (characters such as . and spaces become _), and rewrite the rules for any name that then contains __ or ends in _ to the wildcard form.

Related reads

• Claude Code Hook Failures: onFailure Block Tested
• Claude Code updatedInput Hooks: 2.1.300 Change Tested
• Claude Code Mods: 10 Tested Use Cases (2026)
• MCP Token Audience Check: expectedResource Tested (2026)

Bottom Line

In my claude -p runs on 2.1.299 and 2.1.307, an allow rule of mcp__a reached only the server named a. That narrows what the rule matches, and it breaks any -p allow rule that relied on mcp__a also covering a__b. The docs say a rule like mcp__a__b is read as server a, so use mcp__a__b__* for a__b.

Check every server name in your config. If a normalized name contains __ or ends in _, write mcp__<name>__* for allows. Use per-tool rules to deny the shorter-named server without touching the look-alike, and run one call per server to confirm.

References