Perforce P4 MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

modify_reviews

Create, update, or delete Perforce reviews: vote, transition status, manage comments, participants, and changelists with WRITE permission.

Instructions

Create/update/delete reviews (WRITE permission)

Input Schema

TableJSON Schema

Name	Required	Description
`body`	No	Comment body (required for add_comment, reply_comment)
`jobs`	No	Associated job IDs for transition
`action`	Yes	Review modification action. To delete/obliterate review, use 'obliterate' action which requires approval
`notify`	No	Notification mode
`cleanup`	No	Perform cleanup for approved:commit/committed transitions
`version`	No	Review version (optional for vote)
`change_id`	No	Changelist ID (required for create, append_change, replace_with_change)
`review_id`	No	Review ID (required for most actions except create, archive_inactive)
`reviewers`	No	List of reviewers
`comment_id`	No	Comment ID (reply_comment, edit_comment, mark_comment_read/unread)
`fix_status`	No	Job fix status when transitioning
`new_author`	No	New author username (update_author)
`task_state`	No	Task state. add_comment accepts only 'open'\|'comment'; edit_comment additionally accepts 'addressed'\|'verified'
`transition`	No	Transition target state
`vote_value`	No	Vote value
`description`	No	Review description (optional on create)
`max_reviews`	No	Maximum number of inactive reviews to archive (0 = no limit)
`comment_content`	No	Content lines used to anchor an inline comment to the correct diff position (add_comment). Supply the code line the comment is on plus the four preceding lines, each terminated with a newline character ('\n'). Must be supplied together with comment_left_line and comment_right_line.
`comment_version`	No	Review version for comment attachment
`new_description`	No	New review description (update_description)
`comment_file_path`	No	File path for inline comment
`comment_left_line`	No	Left diff line number for inline comment
`not_updated_since`	No	ISO date (YYYY-MM-DD) threshold for archive_inactive
`comment_right_line`	No	Right diff line number for inline comment
`required_reviewers`	No	List of required reviewers
`reviewer_group_names`	No	List of reviewer group names
`participant_user_names`	No	List of participant usernames
`participant_group_names`	No	List of participant group names
`reviewer_groups_required`	No	List of required reviewer groups
`participant_users_required`	No	List of required participant usernames
`participant_groups_required`	No	List of required participant groups

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv2026.4.3078076Sep 28, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "create",
-  "refresh_projects",
-  "vote",
-  "transition",
-  "append_participants",
-  "add_comment",
-  "reply_comment",
-  "append_change",
-  "replace_with_change",
-  "join",
-  "archive_inactive",
-  "mark_comment_read",
-  "mark_comment_unread",
-  "mark_all_comments_read",
-  "mark_all_comments_unread",
-  "update_author",
-  "update_description",
-  "replace_participants",
-  "delete_participants",
-  "leave",
-  "obliterate"
-]New value: +[
+  "create",
+  "refresh_projects",
+  "vote",
+  "transition",
+  "append_participants",
+  "add_comment",
+  "reply_comment",
+  "edit_comment",
+  "append_change",
+  "replace_with_change",
+  "join",
+  "archive_inactive",
+  "mark_comment_read",
+  "mark_comment_unread",
+  "mark_all_comments_read",
+  "mark_all_comments_unread",
+  "update_author",
+  "update_description",
+  "replace_participants",
+  "delete_participants",
+  "leave",
+  "obliterate"
+]

addedInput schema / properties / comment_content

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Content lines used to anchor an inline comment to the correct diff position (add_comment). Supply the code line the comment is on plus the four preceding lines, each terminated with a newline character ('\\n'). Must be supplied together with comment_left_line and comment_right_line.",
+  "examples": [
+    [
+      "def example_function():\n",
+      "    pass\n"
+    ]
+  ]
+}

changedInput schema / properties / comment_id / description

Previous value: -"Parent comment ID (reply_comment, mark_comment_read/unread)"New value: +"Comment ID (reply_comment, edit_comment, mark_comment_read/unread)"

changedInput schema / properties / task_state / anyOf

Previous value: -[
-  {
-    "enum": [
-      "open",
-      "comment"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "open",
+      "comment",
+      "addressed",
+      "verified"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / task_state / description

Previous value: -"Task state"New value: +"Task state. add_comment accepts only 'open'|'comment'; edit_comment additionally accepts 'addressed'|'verified'"

First observedv2026.3.2996147Jul 29, 2026

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses only the WRITE permission requirement, but omits critical behavioral traits such as destructive actions (e.g., obliterate requiring approval), side effects, notification behavior, and reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no wasted words, front-loading the core purpose. However, given the tool's complexity and 31 parameters, it is arguably undersized for the amount of missing operational context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 31-parameter mutation tool with no annotations, the description is far too sparse. It omits action semantics, usage context, safety disclosures, and prerequisites, relying entirely on the schema and output schema to fill the gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 31 parameters are thoroughly documented in the schema. The description adds no parameter-level meaning beyond what the schema already provides, which is the baseline when coverage is high.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb set (create/update/delete) and resource (reviews), and distinguishes write operations via 'WRITE permission'. However, the stated scope omits many supported actions (vote, transition, comments, participants), so an agent might underestimate the tool's full capabilities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides no guidance on when to use this tool versus alternatives like query_reviews or modify_* siblings. The only hint is 'WRITE permission', which implies a prerequisite but does not explain use cases, exclusions, or required context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server