Multi Mail

Set the vacation responder

settings_update_vacation

DestructiveIdempotent

Turn the automatic reply - out-of-office, auto-reply or vacation responder - on or off, or change what it says. What this call does not name is kept: its schedule, who it answers, and its words when it is turned off; a schedule it keeps, even one that has ended, still decides when it answers. An Outlook mailbox turned on from off answers from then on, whatever schedule it held, and holds no subject.

Input Schema

Name	Required	Description
`mailbox`	Yes	The mailbox's name or its email address.
`enableAutoReply`	Yes	Whether the mailbox answers automatically.
`responseSubject`	No	The subject the answer carries.
`responseBodyPlainText`	No	What the answer says.

Output Schema

Name	Required	Description	Default
`status`	No
`endTime`	Yes
`startTime`	Yes
`enableAutoReply`	Yes
`responseSubject`	Yes
`externalAudience`	No
`responseBodyHtml`	Yes
`restrictToDomain`	Yes
`restrictToContacts`	Yes
`externalReplyMessage`	No
`internalReplyMessage`	No
`scheduledEndDateTime`	No
`responseBodyPlainText`	Yes
`scheduledStartDateTime`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 8, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed26 schema fields changedOct 6, 2026

removedOutput schema / properties / endTime / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / endTime / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / externalAudience / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / externalAudience / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / externalReplyMessage / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / externalReplyMessage / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / internalReplyMessage / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / internalReplyMessage / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / responseBodyHtml / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / responseBodyHtml / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / responseBodyPlainText / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / responseBodyPlainText / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / responseSubject / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / responseSubject / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / restrictToContacts / anyOf

Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / restrictToContacts / type
```
Added value: +[
+  "boolean",
+  "null"
+]
```

removedOutput schema / properties / restrictToDomain / anyOf

Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / restrictToDomain / type
```
Added value: +[
+  "boolean",
+  "null"
+]
```

removedOutput schema / properties / scheduledEndDateTime / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / scheduledEndDateTime / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / scheduledStartDateTime / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / scheduledStartDateTime / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / startTime / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / startTime / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / status / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / status / type
```
Added value: +[
+  "string",
+  "null"
+]
```

First observedOct 5, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description provides deep operational context regarding scheduling persistence. It explicitly states that schedules are kept even when the responder is off and notes the specific behavior of losing the subject line when the mailbox is turned on from an off state.

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?

The description is slightly long, but its density of information justifies the length. It avoids filler and focuses exclusively on high-value operational constraints and behaviors.

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?

Given the complexity of how scheduling and state persistence work in this system, the description is exceptionally complete. It covers edge cases like previously ended schedules, which is critical for agent accuracy.

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?

Since the input schema provides 100% coverage for all parameters, the baseline score of 3 is maintained. The description only elaborates on the semantic purpose of changing the body or subject, rather than compensating for missing schema detail.

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?

The tool clearly defines its purpose as managing the 'vacation responder,' covering both enabling/disabling and modifying the content. It is distinct from general draft tools or list operations in the provided sibling list.

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

Usage Guidelines4/5

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

The description clearly explains the boundaries of the operation—what can be changed (content, status). While it doesn't explicitly name the contrasting tool, the focus on modification vs. retrieval guides usage effectively.

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

All Multi Mail tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.