Feature Request: Add wildcard support for MCP tool permissions

Title: Feature Request: Add wildcard support for MCP tool permissions

Labels: enhancement, feature-request, mcp, permissions

Is your feature request related to a problem? Please describe.

Configuring permissions for Model Context Protocol (MCP) tools is currently inflexible and does not scale well for MCP servers that expose a large number of tools (e.g., Jira, GitHub, Sentry).

According to the current [Identity and Access Management documentation](/en/docs/claude-code/iam), MCP permissions do not support wildcards. Administrators have two options:

1. Allow an entire server by its name (e.g., mcp__github).
2. Explicitly list every single tool individually (e.g., mcp__github__get_issue, mcp__github__list_issues).

This "all or nothing" approach for a given server creates a significant administrative burden. For example, to allow all read-only actions (like get_*, list_*, search_*) from a server, an administrator must manually list dozens of tools. If the MCP server adds a new read-only tool, the policy must be manually updated. This process is tedious, error-prone, and difficult to maintain.

Describe the solution you'd like

I propose adding support for wildcards (*) in MCP permission rules within the permissions section of settings.json and the --allowedTools/--disallowedTools CLI flags.

This would bring MCP permission handling in line with other tools like Bash, which already supports wildcard matching (e.g., Bash(npm run test:*)).

Example Use Cases:

• Allow all tools from a specific server:
• mcp__github__*
• This would be an intuitive, consistent alternative to the current mcp__github syntax.

• Allow a subset of tools based on a prefix:
• mcp__jira__get_*
• This would allow tools like get_issue, get_sprint, get_project, etc., without needing to list each one. This is perfect for granting broad read-only access.

• Allow tools with a common action across all servers:
• mcp__*__list_*
• This would allow list_issues from Jira, list_prs from GitHub, list_files from a filesystem server, etc. This enables the creation of powerful, role-based policies (e.g., an "auditor" role that can list resources but not modify them).

Describe alternatives you've considered

The only current alternative is to manually maintain an exhaustive list of every allowed MCP tool. This is not a scalable solution for enterprise environments where new tools are frequently added to MCP servers. While allowing the entire server (e.g., mcp__github) is an option, it often grants more permissions than necessary, which is contrary to the principle of least privilege.

Additional context

Implementing wildcard support for MCP tools would provide several key benefits:

• Simplified Administration: Drastically reduces the complexity of managing permissions for feature-rich MCP servers.
• Improved Security: Allows for the creation of more granular, pattern-based rules that are safer than allowing an entire server.
• Consistency: Aligns the behavior of MCP permissions with the existing wildcard support for other tools, making the entire permission system more predictable and easier to learn.