Claude Code MCP権限ルール — server:tool単位の書き方
MCP権限ルールのmcp__サーバー名__ツール名記法を、allow/denyの非対称な粒度・評価順・Cowork環境での対応関係まで、設定の書き方に絞ってまとめています。
MCP権限ルールはmcp__サーバー名__ツール名という名前空間でサーバー単位・ツール単位に許可・拒否を書けます。どのサーバーをどこまで信用するかという判断基準はMCPセキュリティガイドにまとめているので、本記事はルールそのものの書き方と、settings.jsonにどう落とし込むかに絞って扱います。
MCP権限ルールの基本構文
MCPのツール名はmcp__<サーバー名>__<ツール名>という形式で公開されます。権限ルールはこの名前空間に対して3段階の粒度で書けます。
| 書き方 | 対象範囲 |
|---|---|
mcp__puppeteer | 対象範囲puppeteerサーバーが提供する全ツール |
mcp__puppeteer__* | 対象範囲同上(ワイルドカード表記。挙動は上と同じ) |
mcp__puppeteer__puppeteer_navigate | 対象範囲puppeteerサーバーのpuppeteer_navigateツールのみ |
settings.jsonのpermissions.allowまたはpermissions.deny配列に、この形式の文字列をそのまま入れます。
{
"permissions": {
"deny": ["mcp__github__delete_repository"],
"allow": ["mcp__github__list_pull_requests", "mcp__github__get_pull_request"]
}
}ここで書ける形式には制限があります。Bash(rm *)のように括弧で引数パターンを絞る書き方はMCPツール名には使えません。settings.json読み込み時、括弧付きのmcp__ルールはすべてスキップされ、claude doctorと起動時のinvalid-settingsダイアログに列挙されます。ツール名まではmcp__サーバー名__ツール名で個別指定できますが、その先の引数レベルで一致条件を絞りたい場合は--disallowedToolsに渡します。
allowは狭く、denyは広く書ける非対称設計
denyルールはグロブパターンを使えます。mcp__*と書けば、サーバーをまたいで全MCPツールを一括拒否できます。一方allowルールはmcp__<サーバー名>__というリテラルな接頭辞が必須で、サーバー名部分をグロブにすることはできません。*やmcp__*のような接頭辞なしのallowグロブは警告付きでスキップされ、何も自動承認しません。
ただし接頭辞さえ具体的なサーバー名で固定していれば、その後ろのツール名部分はグロブにできます。mcp__github__get_*と書けばget_で始まるツールだけをまとめて許可でき、mcp__puppeteer__*のようにサーバー全体を許可することもできます。制限されているのはあくまでサーバー名部分だけです。
denyルールやaskルールで存在しないツール名を指定すると、起動時にタイポを検知する警告が出ます(ツール名に_や*を含む場合はこの警告の対象外)。
つまり「危険なものを広く止める」側は柔軟に書けますが、「安全なものを広く許可する」側は必ずサーバー名まで具体化する必要があります。個別ツールを積み上げて許可し、拒否だけは大きな網で掛けるのが、この非対称性に沿った運用です。
裸のルールはコンテキストごとツールを消す
権限ルール全般には、Bashのように名前だけを書く「裸の(ツール名だけの)ルール」と、Bash(rm *)のように括弧で引数パターンまで絞る「スコープ付きルール」の区別があります。裸の名前をdenyすると、そのツールはClaudeのコンテキストから完全に除去され、Claudeはツールが存在すること自体を認識しません。一方、括弧で範囲を絞ったスコープ付きルールは、ツール自体をコンテキストに残したまま、一致する呼び出しだけを拒否します。
MCPツール名にはこのスコープ付き記法が使えません(前節のとおり、括弧付きのmcp__ルールは設定読み込み時にスキップされます)。つまりmcp__github__delete_repositoryのようにツール名まで書いた形も、mcp__githubのようにサーバー名だけの形も、どちらも括弧のない裸の名前です。denyに書けば、粒度がサーバー単位でもツール単位でも、対象はClaudeのコンテキストから完全に除去されます。個別ツールだけをコンテキストに残したまま呼び出し時に止める、という運用はMCPツールではできません。
読み取り系ツールと書き込み系ツールが混在するサーバーでは、危険なツール名だけを個別にdenyへ列挙すれば、そのツールだけがコンテキストから消え、他のツールは通常どおり残ります。サーバー全体を隠したい場合はmcp__githubやmcp__github__*のようにサーバー名だけを書きます。
ルールの評価順は他のツールと同じくdeny → ask → allowで、最初に一致したものが採用されます。範囲の広いdenyは、範囲の狭いallowが同時に存在していても優先されます。
組織のコネクタ設定は自分のallowルールより強い
組織がclaude.aiコネクタの特定ツールをaskに設定し、その設定がセッションに届いている場合、そのツールへのallowルールは効きません。autoモードでもbypassPermissionsモードでも、Claude Codeは毎回プロンプトを出します。dontAskモード(一切プロンプトを出さないモード)ではさらに一歩進み、プロンプトの代わりに拒否します。Claude Code自身が取得したコネクタのツールはmcp__claude_ai_<サーバー名>__<ツール名>という名前で現れます。
サーバー側が「毎回確認」を強制するrequiresUserInteraction
MCPサーバーの実装者は、特定のツールに_meta["anthropic/requiresUserInteraction"]をtrueと設定することで、そのツールだけ自分の権限ルールでは迂回できない「毎回確認」を強制できます(Claude Code v2.1.199以降)。
{
"name": "grant_repository_access",
"_meta": {
"anthropic/requiresUserInteraction": true
}
}このマークが付いたツールは、allowルールで許可していても、acceptEdits auto bypassPermissionsのどのモードでもプロンプトが出ます。「今後も確認しない」の選択肢も提示されません。dontAskモード(そもそもプロンプトを出さないモード)では、プロンプトの代わりに拒否されます。同意そのものがツールの目的(アクセス権限の付与など)である場合に、誰も同意していないのに処理が進んでしまう事態を防ぐための仕組みで、同じサーバーの他のツールには影響しません。
非対話環境では扱いが変わります。--permission-prompt-toolを使う非対話モードでは、このマークが付いたツールへのallow判定はMCP tool requires user interaction; not supported via --permission-prompt-toolというメッセージ付きでdenyに変換されます。一方、Agent SDKのcanUseToolコールバックはこの呼び出しを受け取れます。SDKを使ったアプリケーション側で人に見せて承認を得ることが前提になっているためです。Remote Controlなど1タップで承認できる面でも、このマークが付いたツールだけはワンタップ操作を使わせず、通常の確認プロンプトを表示します。
自分のallowルールやpermissionModeの設定では、このマークを外すことはできません。信頼できないサーバーが実装したrequiresUserInteraction付きツールに遭遇した場合、拒否したいなら通常どおり個別のdenyルールで対応します。
Cowork環境ではBash/WebFetchのdenyルールがMCPツールに波及する
Claude DesktopアプリのCoworkセッションでは、ClaudeはビルトインのBashツールではなくCoworkのmcp__workspace__bashというMCPツール経由でシェルコマンドを実行します。同様にWeb取得もmcp__workspace__web_fetchというMCPツールが担います。
ここで注意が必要なのは、BashやWebFetchというツール名全体を対象にしたdenyルールは、これらのCoworkツールにも適用される点です。管理設定でBashをdenyしていれば、Coworkセッションでのシェルコマンド実行も止まります。ただしこの波及はdeny方向だけです。Bashのallowルールを設定していても、それがmcp__workspace__bashに自動的に適用されることはありません。Claude Codeがこの呼び出しをブロックしたときのメッセージは、Coworkツールの名前で表示されます(Permission to use mcp__workspace__bash has been denied.)。
組織で「Bashは全環境で禁止」のようなポリシーをCoworkにも確実に効かせたい場合はこの波及を利用できますが、逆に「Coworkだけは自由に許可したい」という設計では、Bashのallowルールでは足りず、mcp__workspace__bashを名指しでallowに追加する必要があります。
同じ記法は権限ルール以外でも使う
mcp__<サーバー名>__<ツール名>という完全な名前は、permissions.allow / permissions.denyだけでなく、複数の場所で同じ形式のまま使えます。
- Skillの
allowed-toolsリスト: スキル定義でそのスキルが使えるツールを絞る際に、同じ名前をそのまま書けます - サブエージェントの
toolsフィールド: サブエージェントの権限設計で使う許可・拒否リストも同じ名前空間を共有します - フックのmatcher:
PreToolUseなどのフックで、特定のMCPツール呼び出しだけを狙って条件処理を挟めます
フックのmatcherを正規表現で書く場合は注意が必要です。プラグインが同梱するMCPサーバーは、サーバー名がプラグイン名で修飾された完全な名前を持ちますが、mcp__database-tools__.*のようにプラグイン修飾前の素のサーバー名(サーバー名だけ)で書いたmatcherは、プラグイン同梱サーバーには一切マッチしません。プラグイン経由のMCPサーバーをフックで狙う場合は、/mcpで実際の完全な名前を確認してからmatcherを書きます。
もう1つの落とし穴は表示名と正規名の違いです。トランスクリプトや確認プロンプトに表示される名前が、権限ルールで書くべき正規名と一致しないツールがあります(組み込みツールの例では、画面上「Stop Task」と表示されるツールの正規名はTaskStopです)。権限ルールとフックのmatcherは正規名にしかマッチしないため、画面表示をそのまま書き写すと一致しません。deny・askルールなら起動時の警告で気づけますが、確実なのは/mcpやツールリファレンスで正規名を確認してから書くことです。
用途別の設定レシピ
| 用途 | 書き方 | 補足 |
|---|---|---|
| 読み取り専用のDB接続だけ許可 | 書き方allowにmcp__postgres__queryを個別列挙、denyにmcp__postgres__execute | 補足書き込み系ツール名を確認してから個別denyを積む |
| Puppeteerサーバーを全面的に信頼 | 書き方allowにmcp__puppeteer(またはmcp__puppeteer__*) | 補足サーバー内の全ツールが同じ信頼度のときだけ使う |
| GitHubサーバーで削除系だけ止める | 書き方denyにmcp__github__delete_repositoryなど個別ツール名 | 補足他のツールはコンテキストに残したまま個別に遮断できる |
| 全MCPサーバーを一括で無効化 | 書き方denyにmcp__* | 補足allow側では同じ書き方はできない非対称設計に注意 |
| Coworkのシェル実行だけ会社ポリシーで禁止 | 書き方denyにBash | 補足mcp__workspace__bashにも自動的に波及する |
よくあるつまずき
mcp__*をallowに書いたのに何も許可されない: allowルールはサーバー名の接頭辞が必須で、サーバー名部分のグロブは無効です。警告付きでスキップされ、意図した許可は何も起きません。個別サーバー名まで書き直します- サーバーの一部ツールだけをdenyしたつもりが、サーバー全体がコンテキストから消えた: MCPツール名にスコープ付き(括弧で範囲を絞る)記法は使えないため、
mcp__<サーバー名>__<ツール名>という個別指定も裸の名前として扱われ、そのツールはコンテキストごと消えます。サーバー内の他のツールを残したい場合は、消したいツール名だけを個別にdenyへ列挙します BashのallowルールをCoworkにも効かせたいのに反映されない: allow方向の波及はサーバー間で起きません。mcp__workspace__bashを明示的にallowへ追加します- 組織のコネクタ設定で
askにしたツールが、個人のallowルールで自動承認されてしまうと思っていた: 組織側のask設定はユーザー側のallowルールより優先されます。個人設定では上書きできません
よくある質問
mcp__serverとmcp__server__*に違いはありますか
対象範囲は同じで、どちらもそのサーバーの全ツールにマッチします。__*はワイルドカード表記としての書き方の違いだけです。
個別ツール名はどこで確認できますか
/mcpコマンドで接続済みサーバーとツール一覧を確認できます。ツール名はサーバーの実装依存のため、公式ドキュメントかサーバー自体の一覧で確認してから権限ルールに書きます。
allowルールでもサーバー名の接頭辞を省略できないのはなぜですか
接頭辞なしのグロブを許可すると、将来追加される未知のMCPサーバーのツールまで意図せず自動承認してしまう恐れがあるためです。拒否は広く、許可は狭くという非対称設計は、この事故を防ぐための仕様です。
requiresUserInteractionが付いたツールをallowルールで自動承認できませんか
できません。このマークはサーバー側の実装で付与されるもので、allowルールやbypassPermissionsモードなど自分側の設定では上書きできません。毎回のプロンプトを前提にした設計として扱います。
CoworkのMCPツールにも通常のMCP権限ルールをそのまま書けますか
mcp__workspace__bashやmcp__workspace__web_fetchは名前としては通常のMCPツールと同じ形式なので、mcp__workspace__bashのように個別に指定するルールはそのまま書けます。異なるのは、ビルトインのBash・WebFetchというツール名を対象にしたdenyルールがこれらにも波及する点だけです。
まとめ
MCP権限ルールはmcp__サーバー名__ツール名の3段階粒度で書け、denyは広く・allowは狭くという非対称なルールがあります。裸のツール名だけのルールをdenyすると、対象はサーバー単位でもツール単位でもコンテキストごと除去されます。MCPツールには括弧で範囲を絞るスコープ付き記法自体が使えないため、呼び出し時だけ止めるという運用はできません。Cowork環境ではBash・WebFetchのdenyルールが対応するMCPツールにも波及しますが、allowルールは波及しないという片方向の挙動に注意が必要です。どのサーバーをどこまで信用すべきかという判断基準はMCPセキュリティガイド、サーバーの追加方法とスコープ指定はClaude Code MCP設定ガイド、権限ルール全体の管理は/permissionsコマンドで扱っています。