grr

Overview Schema Source Related Servers Discussions Admin

gmail.users.messages.get

Retrieves a specific Gmail message by user and message ID, returning JSON with selectable minimal, full, raw, or metadata content for inspection or processing.

Instructions

Gets the specified message [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: batchDelete, batchModify, delete, import, insert, list, modify, send, trash, untrash.

Input Schema

Name	Required	Description	Default
`id`	Yes	[URL path segment] The ID of the message to retrieve. This ID is usually retrieved using `messages.list`. The ID is also contained in the result when a message is inserted (`messa
`query`	No	Extra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
`format`	No	[query parameter] The format to return the message in. Values: `minimal` = Returns only email message ID and labels; does not return the email headers, body, or payload.; `full` = Returns the full email message data with body content parsed in the `payload` field; the `raw` field is not used. Format cannot be used when accessing the api using the gmail.metadata scope.; `raw` = Returns the full email message data with body content in the `raw` field as a base64url encoded string; the `payload` field is not used. Format cannot be used when accessing the api using the gmail.metadata scope.; `metadata` = Returns only email message ID, labels, and email headers..	full
`params`	No	Parameter map merged into the request; typed parameters win.
`userId`	Yes	[URL path segment] The user's email address. The special value `me` can be used to indicate the authenticated user.	me
`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.
`metadataHeaders`	No

Output Schema

Name	Required	Description	Default
`id`	No
`raw`	No
`payload`	No
`snippet`	No
`labelIds`	No
`threadId`	No
`historyId`	No
`internalDate`	No
`sizeEstimate`	No
`classificationLabelValues`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 26, 2026

addedInput schema / properties / format / default
```
Added value: +"full"
```

changedInput schema / properties / format / description

Previous value: -"The format to return the message in."New value: +"[query parameter] The format to return the message in. Values: `minimal` = Returns only email message ID and labels; does not return the email headers, body, or payload.; `full` = Returns the full email message data with body content parsed in the `payload` field; the `raw` field is not used. Format cannot be used when accessing the api using the gmail.metadata scope.; `raw` = Returns the full email message data with body content in the `raw` field as a base64url encoded string; the `payload` field is not used. Format cannot be used when accessing the api using the gmail.metadata scope.; `metadata` = Returns only email message ID, labels, and email headers.."

changedInput schema / properties / id / description

Previous value: -"The ID of the message to retrieve. This ID is usually retrieved using `messages.list`. The ID is also contained in the result when a message is inserted (`messa"New value: +"[URL path segment] The ID of the message to retrieve. This ID is usually retrieved using `messages.list`. The ID is also contained in the result when a message is inserted (`messa"

changedInput schema / properties / metadataHeaders / items / description

Previous value: -"When given and format is `METADATA`, only include headers specified."New value: +"[query parameter] When given and format is `METADATA`, only include headers specified."

addedInput schema / properties / userId / default
```
Added value: +"me"
```

changedInput schema / properties / userId / description

Previous value: -"The user's email address. The special value `me` can be used to indicate the authenticated user."New value: +"[URL path segment] The user's email address. The special value `me` can be used to indicate the authenticated user."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "classificationLabelValues": {
+      "items": {
+        "properties": {
+          "fields": {
+            "items": {
+              "properties": {
+                "fieldId": {
+                  "type": "string"
+                },
+                "selection": {
+                  "type": "string"
+                }
+              },
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "labelId": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "historyId": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "internalDate": {
+      "type": "string"
+    },
+    "labelIds": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "payload": {
+      "properties": {
+        "body": {
+          "properties": {
+            "attachmentId": {
+              "type": "string"
+            },
+            "data": {
+              "type": "string"
+            },
+            "size": {
+              "type": "integer"
+            }
+          },
+          "type": "object"
+        },
+        "filename": {
+          "type": "string"
+        },
+        "headers": {
+          "items": {
+            "properties": {
+              "name": {
+                "type": "string"
+              },
+              "value": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "mimeType": {
+          "type": "string"
+        },
+        "partId": {
+          "type": "string"
+        },
+        "parts": {
+          "items": {
+            "properties": {
+              "body": {
+                "properties": {
+                  "attachmentId": {
+                    "type": "string"
+                  },
+                  "data": {
+                    "type": "string"
+                  },
+                  "size": {
+                    "type": "integer"
+                  }
+                },
+                "type": "object"
+              },
+              "filename": {
+                "type": "string"
+              },
+              "headers": {
+                "items": {
+                  "properties": {
+                    "name": {
+                      "type": "string"
+                    },
+                    "value": {
+                      "type": "string"
+                    }
+                  },
+                  "type": "object"
+                },
+                "type": "array"
+              },
+              "mimeType": {
+                "type": "string"
+              },
+              "partId": {
+                "type": "string"
+              },
+              "parts": {
+                "items": {
+                  "properties": {
+                    "body": {
+                      "type": "object"
+                    },
+                    "filename": {
+                      "type": "string"
+                    },
+                    "headers": {
+                      "items": {
+                        "type": "object"
+                      },
+                      "type": "array"
+                    },
+                    "mimeType": {
+                      "type": "string"
+                    },
+                    "partId": {
+                      "type": "string"
+                    },
+                    "parts": {
+                      "items": {
+                        "type": "object"
+                      },
+                      "type": "array"
+                    }
+                  },
+                  "type": "object"
+                },
+                "type": "array"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "raw": {
+      "type": "string"
+    },
+    "sizeEstimate": {
+      "type": "integer"
+    },
+    "snippet": {
+      "type": "string"
+    },
+    "threadId": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 26, 2026

TDQS

C2.8/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 behavioral burden. It discloses 'HTTP GET' and that it returns JSON, but then spends space describing request-body construction and body_file, which are irrelevant for a GET endpoint and add confusing noise rather than clarity about side effects, auth scopes, or format-specific constraints.

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

Conciseness2/5

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

The purpose is front-loaded, but the middle clause about request bodies and body_file is boilerplate that does not apply to a GET operation and distracts from the tool's actual behavior. The long sibling list is arguably useful for routing, but the overall composition wastes attention on irrelevant mechanics.

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?

Given an output schema and 88% schema coverage, the description need not explain return values. However, with no annotations, it should do more to disclose read-only behavior, auth scope constraints, and format-specific caveats; it is minimally adequate but leaves important behavioral context unstated.

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 88%, so the schema already documents the key parameters thoroughly. The description adds generic precedence semantics for the params map and body_file, but nothing specific about the message id, format enum, or metadataHeaders that would supplement the schema meaningfully.

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?

The first sentence states a specific verb and resource: 'Gets the specified message', which makes the operation immediately clear. It also names the sibling operations on the same resource, though it does not explain how the purpose differs from adjacent reads like threads.get or messages.list.

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?

There is no explicit guidance on when to use this tool versus alternatives such as messages.list, threads.get, or attachments.get. The sibling list provides awareness but no selection criteria, so the agent must infer usage entirely.

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

Deploy Server