Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix MCP permission rules: support argument matching (analogous to Bash(cmd *)) [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48282•Fetched 2026-04-16 07:04:12
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
shalalalawshalalalaw
Participants
github-actions[bot]github-actions[bot]shalalalawshalalalaw
Timeline (top)
labeled ×3commented ×1

Claude Code's MCP permission grammar currently supports only server/tool granularity:

  • mcp__<server>
  • mcp__<server>__*
  • mcp__<server>__<tool>

There is no way to match on tool arguments, analogous to Bash(cmd *) or WebFetch(domain:...). Requesting something like:

mcp__gateway__gateway_invoke_tool(name:gmail_*)
mcp__gateway__gateway_invoke_tool(name:*_delete_*)

Root Cause

Claude Code's MCP permission grammar currently supports only server/tool granularity:

  • mcp__<server>
  • mcp__<server>__*
  • mcp__<server>__<tool>

There is no way to match on tool arguments, analogous to Bash(cmd *) or WebFetch(domain:...). Requesting something like:

mcp__gateway__gateway_invoke_tool(name:gmail_*)
mcp__gateway__gateway_invoke_tool(name:*_delete_*)

Fix Action

Workaround

We've shipped a PreToolUse hook that reads tool_input.name and returns allow/ask/deny per inner tool, with prompt text like "Allow gateway_invoke_tool to call gmail_delete_message?". It works, but hooks are heavier than declarative permission rules and require us to reimplement prompt UX.

Code Example

mcp__gateway__gateway_invoke_tool(name:gmail_*)
mcp__gateway__gateway_invoke_tool(name:*_delete_*)

---

mcp__gateway__gateway_invoke_tool(name:gmail_*)         # allow all gmail tools
mcp__gateway__gateway_invoke_tool(name:*_delete_*)      # ask before any delete-like tool
RAW_BUFFERClick to expand / collapse

Summary

Claude Code's MCP permission grammar currently supports only server/tool granularity:

  • mcp__<server>
  • mcp__<server>__*
  • mcp__<server>__<tool>

There is no way to match on tool arguments, analogous to Bash(cmd *) or WebFetch(domain:...). Requesting something like:

mcp__gateway__gateway_invoke_tool(name:gmail_*)
mcp__gateway__gateway_invoke_tool(name:*_delete_*)

Motivation

Gateway / meta-tool patterns — including Claude Code's own internal deferred-tools/ToolSearch design — collapse many underlying tools into one permission name, destroying per-tool approval UX.

Our use case: we run an MCP gateway that lazy-loads ~300 tools behind three meta-tools (gateway_list_tools, gateway_describe_tool, gateway_invoke_tool). After this collapse, every tool call shows up as gateway_invoke_tool regardless of whether the inner tool is gmail_search_messages or gmail_delete_message — so users can't grant fine-grained approvals.

Workaround

We've shipped a PreToolUse hook that reads tool_input.name and returns allow/ask/deny per inner tool, with prompt text like "Allow gateway_invoke_tool to call gmail_delete_message?". It works, but hooks are heavier than declarative permission rules and require us to reimplement prompt UX.

Proposal

Extend MCP permission rule grammar to accept a parenthesized specifier that matches structured tool_input fields, at minimum name:<glob>. Ideally the syntax mirrors existing tools (Bash(cmd *)), so:

mcp__gateway__gateway_invoke_tool(name:gmail_*)         # allow all gmail tools
mcp__gateway__gateway_invoke_tool(name:*_delete_*)      # ask before any delete-like tool

Docs reference

Current MCP permission rule grammar: https://code.claude.com/docs/en/permissions#mcp

extent analysis

TL;DR

Extend the MCP permission rule grammar to support matching on tool arguments using a parenthesized specifier, such as mcp__gateway__gateway_invoke_tool(name:gmail_*).

Guidance

  • Review the current MCP permission rule grammar documentation to understand the existing syntax and limitations.
  • Consider the proposed syntax mcp__gateway__gateway_invoke_tool(name:gmail_*) and how it can be used to achieve fine-grained approvals for tools behind meta-tools.
  • Evaluate the trade-offs between using the proposed declarative permission rules versus the existing PreToolUse hook workaround, considering factors such as performance and UX implementation.
  • Investigate the feasibility of implementing the proposed syntax, including any potential changes to the MCP permission grammar parser and evaluator.

Example

# Proposed permission rule example
mcp__gateway__gateway_invoke_tool(name:gmail_*)  # allow all gmail tools
mcp__gateway__gateway_invoke_tool(name:*_delete_*)  # ask before any delete-like tool

Notes

The proposed solution relies on extending the existing MCP permission rule grammar, which may require changes to the underlying parser and evaluator. The feasibility and implementation details of this proposal are uncertain and would require further investigation.

Recommendation

Apply the proposed workaround using the PreToolUse hook until the MCP permission rule grammar can be extended to support matching on tool arguments, as it provides a functional solution to the problem, albeit with potential performance and UX trade-offs.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#API rate limit#retriever error#indexing error#inference speed#output truncation

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING