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

Comienza en tools.go, especialmente con las referencias a FeatureFlagPullRequestsGranular y el registro de pull_request_review_write; compáralos con las herramientas granulares existentes para pull requests. Determina cómo hacer que create, submit_pending y delete_pending sean distinguibles para los clientes MCP, preservando al mismo tiempo el comportamiento del indicador de funcionalidades. Se considera completado cuando la capa de permisos puede separar estas operaciones, con pruebas o documentación que cubran el comportamiento resultante.

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.