grr

Overview Schema Source Related Servers Discussions Admin

gmail.users.settings.getVacation

Retrieve Gmail vacation responder settings for a user to review auto-reply status, subject, message, and schedule before updating them.

Instructions

Gets vacation responder settings. For more information, see Manage vacation settings with the Gmail API [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: getAutoForwarding, getImap, getLanguage, getPop, updateAutoForwarding, updateImap, updateLanguage, updatePop, updateVacation.

Input Schema

Name	Required	Description	Default
`query`	No	Extra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
`params`	No	Parameter map merged into the request; typed parameters win.
`userId`	Yes	[URL path segment] 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.

Output Schema

Name	Required	Description	Default
`endTime`	No
`startTime`	No
`enableAutoReply`	No
`responseSubject`	No
`responseBodyHtml`	No
`restrictToDomain`	No
`restrictToContacts`	No
`responseBodyPlainText`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 26, 2026

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

changedInput schema / properties / userId / description

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

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "enableAutoReply": {
+      "type": "boolean"
+    },
+    "endTime": {
+      "type": "string"
+    },
+    "responseBodyHtml": {
+      "type": "string"
+    },
+    "responseBodyPlainText": {
+      "type": "string"
+    },
+    "responseSubject": {
+      "type": "string"
+    },
+    "restrictToContacts": {
+      "type": "boolean"
+    },
+    "restrictToDomain": {
+      "type": "boolean"
+    },
+    "startTime": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 26, 2026

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose the operation is a read ('Gets', '[HTTP GET]') and returns JSON, which is useful. However, it omits auth/scope requirements and instead spends words on a generic request-body/body_file mechanism that is irrelevant to a bodyless GET, which could mislead an agent into supplying a body.

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?

The purpose sentence is correctly front-loaded, but the trailing boilerplate about typed parameters and body_file is template filler that does not apply to a GET and dilutes the signal. The sibling enumeration is long and includes this tool itself.

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

Completeness4/5

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

The tool is a simple single-parameter read and an output schema exists, so return values need not be described. The definition is sufficient to invoke it correctly; the only real gap is the absence of permission/scope context and the slightly confusing body-construction note.

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 the userId parameter and the generic query/params/dry_run/body_file helpers are already documented in the schema; baseline 3 applies. The description adds no meaning about userId or how the 'me' alias behaves beyond what the schema already says.

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 vacation responder settings.' It also enumerates the sibling settings tools, so an agent can see this is the read counterpart to updateVacation. It stops short of explicitly contrasting getVacation against e.g. getAutoForwarding or getImap beyond the shared naming pattern.

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

Usage Guidelines3/5

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

The sibling list implies the get-vs-update distinction, but the description never says when to call this tool versus scanning the other settings endpoints, nor what preconditions (e.g. which account or scope) apply. Usage is inferable from the name rather than stated.

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

Deploy Server