Skip to main content
Glama
littlebearapps

Outlook Assistant

by littlebearapps
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Mailbox Settings

mailbox-settings
DestructiveIdempotent

Read or update mailbox-level settings, including automatic replies and working hours, with dry-run previews before changes apply.

Instructions

Read or update mailbox-level settings (idempotent — safe to retry; sets are PATCH-style and merge with existing state). action=get (default) returns settings — use section to filter (language, timeZone, workingHours, automaticRepliesSetting, or all). action=set-auto-replies configures out-of-office: enabled true/false, optional startDateTime/endDateTime (ISO 8601) for scheduled mode, internalReplyMessage and (optionally) externalReplyMessage and externalAudience (none/contactsOnly/all); pass dryRun: true to preview who would get replies without changing anything. action=set-working-hours updates the schedule: startTime/endTime (HH:MM) and daysOfWeek (array of monday..sunday). Returns the updated settings object on set actions.

Input Schema

NameRequiredDescriptionDefault
actionNoAction to perform (default: get)
dryRunNoPreview only (action=set-auto-replies): nothing is changed. Shows who would get automatic replies, the schedule and each message length. Other actions refuse dryRun and change nothing. Default false.
enabledNoEnable (true) or disable (false) automatic replies (action=set-auto-replies)
endTimeNoWork end time in HH:MM format, e.g. '17:00' (action=set-working-hours)
sectionNoSpecific section to retrieve (action=get, default: all)
timeZoneNoTime zone name, e.g. 'Australia/Melbourne' (action=set-working-hours)
startTimeNoWork start time in HH:MM format, e.g. '09:00' (action=set-working-hours)
daysOfWeekNoWork days, e.g. ['monday','tuesday','wednesday','thursday','friday'] (action=set-working-hours)
endDateTimeNoEnd date/time for scheduled mode, ISO 8601 format (action=set-auto-replies)
startDateTimeNoStart date/time for scheduled mode, ISO 8601 format (action=set-auto-replies)
externalAudienceNoWho receives external reply (action=set-auto-replies)
externalReplyMessageNoReply message for external senders (action=set-auto-replies)
internalReplyMessageNoReply message for internal senders (action=set-auto-replies)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.14.1
    • addedInput schema / properties / dryRun
      Added value: +{
+  "description": "Preview only (action=set-auto-replies): nothing is changed. Shows who would get automatic replies, the schedule and each message length. Other actions refuse dryRun and change nothing. Default false.",
+  "type": "boolean"
+}
  2. Addedv3.9.1
  3. Removedv3.9.0
  4. Changed1 schema field changedv3.7.4
    • addedInput schema / additionalProperties
      Added value: +false
  5. First observedv3.4.1

TDQS

A4.3/5.0
Behavior4/5

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

The description corroborates the idempotentHint annotation ('idempotent — safe to retry') and adds real value beyond structured fields by disclosing PATCH-style merge semantics and the dryRun preview behavior ('nothing is changed'). It also states the return value ('Returns the updated settings object on set actions'). It does not address the destructiveHint annotation directly (i.e., that set actions overwrite existing working hours/auto-reply configuration), so not a 5.

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 read/update framing, then grouped by action, so every sentence maps to a decision the agent must make. It is somewhat dense and re-enumerates enum values already present in the schema, which is redundant length rather than dead weight.

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?

For a 13-parameter, zero-required, multi-action tool with no output schema, the description supplies the missing glue: action semantics, parameter-to-action mapping, formats (ISO 8601, HH:MM), and the return value. Complete enough to invoke correctly; only permission/scoping caveats are absent.

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 schema already documents every parameter, making 3 the baseline. The description adds cross-parameter meaning the schema cannot express: which parameters belong to which action, that startDateTime/endDateTime select scheduled mode, that externalReplyMessage is optional, and that dryRun is rejected for non-set-auto-replies actions.

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 opening clause states a specific verb pair and resource ('Read or update mailbox-level settings') and then enumerates the three actions (get, set-auto-replies, set-working-hours), which no sibling tool covers. An agent can distinguish it from manage-rules, manage-focused-inbox, and access-shared-mailbox 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 Guidelines4/5

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

It gives clear per-action context: action defaults to get, section filters the read, set-auto-replies configures out-of-office, set-working-hours updates the schedule. It also explains the dryRun preview path for set-auto-replies. It does not state when NOT to use this tool or name a preferred alternative for overlapping tasks, so it stops short of a 5.

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

Deploy Server

Other Tools