grr

Overview Schema Source Related Servers Discussions Admin

drive.approvals.get

Retrieve a Drive approval by file and approval ID to inspect its status and details. Use it when you need the current approval record before deciding next steps.

Instructions

Gets an approval by ID. For more information, see Manage approvals [HTTP GET]. Returns the requested resource as JSON — request bodies are built from the typed parameters (typed flags win over the params map), or read whole from body_file Siblings over the same resource: approve, cancel, comment, decline, list, reassign, 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.
`approvalId`	Yes	[URL path segment] Required. The ID of the approval.

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.

Changed3 schema fields changedOct 26, 2026

changedInput schema / properties / approvalId / description

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

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

B3.1/5.0

Behavior3/5

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

With no annotations, the description does carry the safety profile implicitly via "[HTTP GET]" and states the resource is returned as JSON. However, it says nothing about permissions needed to read an approval, error behavior for a nonexistent approvalId, or whether this returns the approval's full history/comments. The body-construction sentences (body_file, typed flags over params) are boilerplate that is irrelevant to a GET and arguably noise.

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

Conciseness3/5

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

Purpose is front-loaded in the first four words, which is good. But the middle sentence about request bodies built from typed parameters or read from `body_file` is dead weight for a GET call, and the trailing sibling enumeration is a naked list with no routing logic.

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

Completeness3/5

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

Output schema exists so return shape needn't be described, and both required path params are covered by the schema. Still, for a zero-annotation read tool in a large API surface, the description lacks permission requirements and failure modes, leaving an agent to discover auth/404 behavior by trial.

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 coverage is 100%, so fileId and approvalId are already fully documented, and passing this tool the two required path segments is obvious. The description's note that typed flags win over the `params` map merely restates the schema line "Parameter map merged into the request; typed parameters win." No added meaning.

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?

"Gets an approval by ID" states a specific verb and resource and is immediately distinguishable from the mutating siblings (approve, cancel, decline). It stops short of contrasting with drive.approvals.list, which returns many approvals and shares the same resource.

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?

The description lists sibling names (approve, cancel, comment, decline, list, reassign, start) but never says when to choose this one over list or any of them. The agent must infer that 'get by ID' vs 'list' is the selection rule; no prerequisites, no when-not-to-use, no required permission context.

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

Deploy Server