我的 MCP 伺服器名稱沒有雙底線，需要改規則嗎？
多半不需要。這次調整主要影響名稱含 __ 或以 _ 結尾的伺服器，一般名稱的 mcp__伺服器 與 mcp__伺服器__* 寫法依文件仍然有效。
仍建議升級後跑一次 claude doctor，確認沒有規則因為含括號或沒有錨點的萬用字元而被略過。
升級後我的自動化突然失敗，可能跟這個有關嗎？
有可能，特別是你用 dontAsk 模式，而且某台伺服器的名稱含 __。舊的寬鬆匹配消失後，工具不再被放行，而 dontAsk 不會詢問，呼叫會被直接拒絕。
先用 claude doctor 看有沒有被略過的規則，再把相關 allow 規則改成 mcp__完整名稱__* 的形式。
deny 規則也受影響嗎？
這次 changelog 寫的是 allow 規則，我沒有查到對 deny 規則的相同說明，所以不能斷言。權限文件另外指出，deny 與 ask 規則可以使用 mcp__* 這種開頭的萬用字元。
涉及封鎖的規則，建議升級後各測一次，確認被擋的伺服器確實被擋。
怎麼找出自己設定裡含雙底線的 MCP 伺服器？
最直接的方法是在 /mcp 列出已設定的伺服器名稱，再逐一檢查是否含有 __ 或以 _ 結尾。外掛提供的伺服器名稱則要看外掛範圍的完整形式。
找到之後，把對應的 allow 規則統一改成 mcp__完整名稱__*，並放進共用設定，讓全團隊用同一套寫法。
Claude Code v2.1.299（2026 年 10 月 14 日）的 Changed 項目有一條安全相關的調整：MCP 的 allow 規則現在只會對上它所指名的那一台伺服器，mcp__a 不再放行名為 a__b 或 a_ 的伺服器；同版本也規定 agent 的 tools: 清單只會取到被點名的 MCP 伺服器的工具。伺服器名稱含有 __ 的人，需要把規則改成 mcp__<完整名稱>__*。
MCP 工具在 Claude Code 裡的完整名稱是 mcp__<伺服器>__<工具>，而 __ 同時是分隔符。官方權限文件現在明確寫出：伺服器名稱若含 __ 或以 _ 結尾，要寫成萬用字元形式 mcp__<伺服器>__* 並帶完整名稱。例如伺服器叫 reports__v2，就寫 mcp__reports__v2__*；裸的 mcp__reports__v2 與較短的 mcp__reports 都不會匹配它的工具，因為 Claude Code 會把這兩種寫法讀成名為 reports 那台伺服器的規則。換句話說，舊版允許規則的範圍可能比寫的人想的更寬（這是我從 changelog 的「不再放行」措辭推得的，官方沒有逐條說明舊行為）。
文件還提到，伺服器名稱中的 . 或空白會變成 _，所以設定為 my.server 的伺服器要寫 mcp__my_server__*；外掛提供的伺服器則用外掛範圍的形式，例如 mcp__plugin_my-plugin_database-tools__*。允許規則的萬用字元也有限制：只能出現在字面的 mcp__<伺服器>__ 前綴之後，伺服器那一段不能含萬用字元；* 或 mcp__* 這類沒有錨點的允許規則會被略過並顯示警告，不會放行任何東西。含括號的 mcp__ 規則在載入時也會被跳過，需要依參數限制時，要改用 --disallowedTools 的 deny 規則。
如果你的某台伺服器名稱含 __，而 allow 規則是靠舊的寬鬆匹配才生效，升級後它的工具會重新開始詢問權限；在 dontAsk 模式下，因為不詢問，這些呼叫會直接被拒絕，自動化流程可能因此突然失敗。這是 fail-closed 的方向，比悄悄放行安全，但會造成中斷。建議升級前先列出所有 MCP 伺服器名稱，找出含 __ 或結尾為 _ 的，並用 claude doctor 檢查被略過的規則。
如果你的團隊用 managed settings 或共用的 settings.json 為 MCP 伺服器預先核准，這次調整是一個很便宜的稽核機會：花十分鐘列出每一條 mcp__ 允許規則，確認它指的就是你以為的那一台伺服器，並把含雙底線的改成完整萬用字元形式。權限規則寫得比實際意圖寬，通常到出事才會發現；這次升級至少讓這類歧義變得可見。