[FEATURE]: Granular permission pattern matching for MCP tools #12358

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Describe the enhancement you want to request

Problem

Granular permission rules (object syntax) documented at https://opencode.ai/docs/permissions/#granular-rules-object-syntax don't work for MCP tools. Pattern matching only applies to built-in tools (bash, edit, read, etc.).
Many MCP tools bundle multiple operations behind a single tool name (e.g., outlook_calendar_meeting with operation=create|read|update|delete). There's no way to allow read-only operations while requiring approval for mutations.
Tested patterns (none matched)

The permission prompt shows MCP tool input as:
outlook_calendar_meeting operation=read, meetingId=AAMk..., meetingChangeKey=DwAA...
Patterns tried in opencode.jsonc — none bypassed the prompt:

"outlook_calendar_meeting": {
  "*": "ask",
  "operation=read*": "allow",
  "*operation=read*": "allow",
  "*\"operation\":\"read\"*": "allow",
  "[operation=read*": "allow"
}

Root cause

As identified in #12111, MCP tools fall through to a generic case in permission.tsx (line 262-264) that doesn't run the input() data through pattern matching the way built-in tools do.
Expected behavior
Granular permission patterns should work for MCP tools the same way they work for built-in tools. Using the displayed format [key=value, ...] as the match string would be consistent:
outlook_calendar_meeting: { *: ask, *operation=read*: allow }

Use case

MCP servers like Outlook, Slack, or database tools often expose a single tool with CRUD operations. Users need to:

• Allow read operations (calendar reads, email inbox) without prompts
• Ask for write operations (sending emails, creating meetings)
• Deny destructive operations (deleting events)

Possible approach

The input() memo in permission.tsx (lines 128-138) already holds the MCP tool parameters. The fix would involve serializing those parameters into a matchable string (e.g., the same key=value, ... format shown in the prompt) and running it through the existing pattern matching logic that built-in tools already use. This could potentially be addressed alongside #12111 since both touch the same MCP fallback path.

Related

• [FEATURE]: Display MCP Tool Parameters in Permission Dialog #12111 — Display MCP tool parameters in permission dialog