`pull_request_review_write` combines create/submit/delete into one tool, making fine-grained permissions by method impossible

tools.go から始め、特に FeatureFlagPullRequestsGranular の参照と pull_request_review_write の登録を確認し、既存の粒度の細かい pull request ツールと比較します。feature flag の動作を維持しながら、create、submit_pending、delete_pending を MCP クライアントが区別できるようにする方法を判断します。権限レイヤーでこれらの操作を分離でき、その結果の動作をカバーするテストまたはドキュメントがあることを完了条件とします。

Today the pull_request_review_write tool consolidates three distinct review operations behind a single tool name with a method enum:

• create
• submit_pending
• delete_pending

The description is:

Create and/or submit, delete review of a pull request.
Available methods:

• create: Create a new review of a pull request. If event parameter is provided, the review is submitted. If event is omitted, a pending review is created.
• submit_pending: Submit an existing pending review of a pull request.
• delete_pending: Delete an existing pending review of a pull request.

This consolidation plays nicely with context/token budgets, but it makes permissions in MCP clients effectively all-or-nothing for these three operations, because most clients (Claude Code, etc.) attach permissions at the tool name level, not on the method argument.

My use case

• I want to always allow create for pending reviews, so the agent can open a pending review and add inline comments.
• But I do not want the agent to be allowed to submit or delete reviews automatically; those should always require explicit human approval (or be disallowed entirely).

With the current API surface, the client can't express this as:

• allow: create_pending_review
• ask/deny: submit_pending_review
• ask/deny: delete_pending_review

because all three are encoded as pull_request_review_write with different method values. There's no way to distinguish them in a tool-level permission model.

Request

Please provide a way to make these operations distinguishable at the tool/permission layer. A few possible approaches:

1. Split into separate tools (preferred for permissioning)

For example:

• create_pending_pull_request_review
• submit_pending_pull_request_review
• delete_pending_pull_request_review

This would let MCP clients and policy engines attach different permissions to creation vs submission/deletion, while still sharing implementation internally.

2. Add a server-side permission hint or annotation per method

If full tool splitting is not desirable, consider some form of metadata/annotation that lets clients understand that:

• method: "create" (without event) is "low-risk, pending-only"
• method: "submit_pending" and method: "delete_pending" are "higher-risk, finalizing/destructive"

so they can enforce stricter prompts or denials for the latter two, even under a single tool name.

3. At minimum, document the permissioning implications

A note in the README or docs that "if your client permission model is per-tool-name, you cannot allow create while denying submit_pending/delete_pending" would help users reason about the tradeoff.

Why this matters

There's a meaningful security and UX distinction between:

• letting an agent open a pending review and propose comments, versus
• letting an agent actually submit or delete reviews without human oversight.

Right now, clients that operate at the MCP tool level either have to:

• allow all three (create + submit_pending + delete_pending), or
• prompt/deny all three,

which removes a useful "middle ground" of: always allow pending review creation, but gate final submission/deletion.

A small API surface adjustment (or richer annotations) would make it much easier for clients to implement that pattern.

Related

• FeatureFlagPullRequestsGranular already exists in the codebase as a feature flag for splitting granular PR tools — this issue is in the same spirit for the review write path.
• The tools.go comment mentions: // Granular pull request tools (feature-flagged, replace consolidated update_pull_request/pull_request_review_write), suggesting this split has already been considered.