grr

Overview Schema Source Related Servers Discussions Admin

drive.approvals.reassign

Reassign reviewers on a Drive approval by adding or replacing reviewer emails while the approval is in progress and the current reviewer has not responded.

Instructions

Reassigns the reviewers on an approval. For more information, see Manage approvals. Adds or replaces reviewers in the ReviewerResponse of the approval. This can be called by any user with the writer permission on the file while the approval Status is IN_PROGRESS and the Response for the reviewer being reassigned is NO_RESPONSE. A user with the reader permission can only reassign an approval that's assigned to themselves. Removing a reviewer isn't allowed [HTTP POST] — creates or triggers a change; refused under --readonly safety profiles. Returns the API's response resource as JSON — request body is a JSON ReassignApprovalRequest object accepting addReviewers, message, replaceReviewers; pass it via params or whole via body_file Siblings over the same resource: approve, cancel, comment, decline, get, list, start.

Input Schema

Name	Required	Description
`query`	No	Extra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
`fileId`	Yes	[URL path segment] Required. The ID of the file that the approval is on.
`params`	No	Parameter map merged into the request; typed parameters win.
`dry_run`	No	Return the request that would be sent, without sending it.
`body_file`	No	Read the request body from this file ('-' for stdin) instead of building one from the parameters. The body is a JSON ReassignApprovalRequest object.
`approvalId`	Yes	[URL path segment] Required. The ID of the approval to reassign.
`request_body`	No	Request body of type ReassignApprovalRequest: pass it via `params` (merged into the built body) or whole via `body_file`.

Output Schema

Name	Required	Description	Default
`kind`	No
`status`	No
`dueTime`	No
`initiator`	No
`approvalId`	No
`createTime`	No
`modifyTime`	No
`completeTime`	No
`targetFileId`	No
`reviewerResponses`	No
`fileContentChangeBehavior`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 26, 2026

changedInput schema / properties / body_file / description

Previous value: -"Read the request body from this file ('-' for stdin) instead of building one from the parameters."New value: +"Read the request body from this file ('-' for stdin) instead of building one from the parameters. The body is a JSON ReassignApprovalRequest object."

addedInput schema / properties / request_body

Added value: +{
+  "description": "Request body of type ReassignApprovalRequest: pass it via `params` (merged into the built body) or whole via `body_file`.",
+  "properties": {
+    "addReviewers": {
+      "items": {
+        "properties": {
+          "addedReviewerEmail": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "message": {
+      "type": "string"
+    },
+    "replaceReviewers": {
+      "items": {
+        "properties": {
+          "addedReviewerEmail": {
+            "type": "string"
+          },
+          "removedReviewerEmail": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changed3 schema fields changedOct 26, 2026

changedInput schema / properties / approvalId / description

Previous value: -"Required. The ID of the approval to reassign."New value: +"[URL path segment] Required. The ID of the approval to reassign."

changedInput schema / properties / fileId / description

Previous value: -"Required. The ID of the file that the approval is on."New value: +"[URL path segment] Required. The ID of the file that the approval is on."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "approvalId": {
+      "type": "string"
+    },
+    "completeTime": {
+      "type": "string"
+    },
+    "createTime": {
+      "type": "string"
+    },
+    "dueTime": {
+      "type": "string"
+    },
+    "fileContentChangeBehavior": {
+      "enum": [
+        "FILE_CONTENT_CHANGE_BEHAVIOR_UNSPECIFIED",
+        "RESET_APPROVAL",
+        "NO_APPROVAL_ACTION"
+      ],
+      "type": "string"
+    },
+    "initiator": {
+      "properties": {
+        "displayName": {
+          "type": "string"
+        },
+        "emailAddress": {
+          "type": "string"
+        },
+        "kind": {
+          "type": "string"
+        },
+        "me": {
+          "type": "boolean"
+        },
+        "permissionId": {
+          "type": "string"
+        },
+        "photoLink": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "modifyTime": {
+      "type": "string"
+    },
+    "reviewerResponses": {
+      "items": {
+        "properties": {
+          "kind": {
+            "type": "string"
+          },
+          "response": {
+            "enum": [
+              "RESPONSE_UNSPECIFIED",
+              "NO_RESPONSE",
+              "APPROVED",
+              "DECLINED"
+            ],
+            "type": "string"
+          },
+          "reviewer": {
+            "properties": {
+              "displayName": {
+                "type": "string"
+              },
+              "emailAddress": {
+                "type": "string"
+              },
+              "kind": {
+                "type": "string"
+              },
+              "me": {
+                "type": "boolean"
+              },
+              "permissionId": {
+                "type": "string"
+              },
+              "photoLink": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "status": {
+      "enum": [
+        "STATUS_UNSPECIFIED",
+        "IN_PROGRESS",
+        "APPROVED",
+        "CANCELLED",
+        "DECLINED"
+      ],
+      "type": "string"
+    },
+    "targetFileId": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it declares the POST semantics, that the call creates/triggers a state change, and that it is refused under --readonly safety profiles. It also discloses the permission model and the return value (the API's response resource as JSON), which is exactly the mutation-risk context an agent needs.

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?

Front-loaded with the core action and every sentence contributes required facts (permissions, status gates, body shape, return type). It runs long and packs them into one dense paragraph with bracketed asides, which slightly hurts scanability but there is no filler.

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

Completeness5/5

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

An output schema exists, so return-format explanation isn't needed, and all 7 parameters are documented in the schema. Combined with the description's permission gates, status preconditions, readonly refusal note, and body-passing options, an agent has everything needed to invoke this correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by naming the three body fields (addReviewers, message, replaceReviewers) and explaining the two delivery paths ('pass it via params or whole via body_file'). That said, it largely restates what request_body's schema description already says, so it does not add deep semantic meaning like field interactions or required-field rules.

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

Purpose5/5

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

States a specific verb and resource ('Reassigns the reviewers on an approval') and immediately clarifies mechanics ('Adds or replaces reviewers in the ReviewerResponse'). It also names the sibling family (approve, cancel, comment, decline, get, list, start), so an agent can place it without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit preconditions: writer permission on the file, Status must be IN_PROGRESS, the target reviewer's Response must be NO_RESPONSE, and a reader may only reassign an approval assigned to themselves. It also states a hard exclusion — removing a reviewer isn't allowed — which routes the agent away from misuse.

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

Deploy Server