Skip to main content
Glama
littlebearapps

Outlook Assistant

by littlebearapps
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Update Email

update-email
Idempotent

Update Outlook message state without changing content: mark read/unread, flag (with due dates), unflag, or complete single or batch messages, including shared mailboxes.

Instructions

Update message state without modifying content (idempotent — safe to retry). action=mark-read/mark-unread sets isRead on a single message by id. action=flag sets a follow-up flag with optional dueDateTime/startDateTime: ISO 8601 with a time, kept as that exact instant when it has Z or a ±hh:mm offset and read in OUTLOOK_DEFAULT_TIMEZONE when it has none; date-only or unparseable values are refused before any change. With only dueDateTime, the start is 09:00 on the due date, or the due time if earlier. action=unflag clears the flag; action=complete marks it done. Flag/unflag/complete take id (single) or ids (batch, updated one at a time: one PATCH each, not Graph $batch). sharedMailbox (alias email) updates messages in a shared/delegated mailbox (default: the signed-in account; needs Mail.ReadWrite.Shared and delegate access). Returns a status per message.

Input Schema

NameRequiredDescriptionDefault
idNoSingle message ID (required for mark-read/mark-unread; flag actions take `id` or `ids`)
idsNoArray of message IDs for batch flag/unflag/complete operations
emailNoAlias for `sharedMailbox`.
actionYesAction to perform (required)
dueDateTimeNoDue date/time for follow-up (action=flag). ISO 8601 with a time: "2026-03-01T09:00:00Z" or "2026-03-01T09:00:00+10:00" is that exact instant; "2026-03-01T09:00:00" (no zone) is read in the default timezone (OUTLOOK_DEFAULT_TIMEZONE).
sharedMailboxNoEmail address of the shared/delegated mailbox whose message(s) to update (default: the signed-in account). Requires delegate access + Mail.ReadWrite.Shared. Work/school only; needs the server opt-in setting OUTLOOK_SHARED_MAILBOX (otherwise the call is refused with setup guidance).
startDateTimeNoStart date/time for follow-up (action=flag), same format as dueDateTime. Defaults to 09:00 on the due date in the default timezone (capped at the due time) when only dueDateTime is given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv3.14.1
    • changedInput schema / properties / dueDateTime / description
      Previous value: -"Due date/time for follow-up, ISO 8601 (action=flag)"New value: +"Due date/time for follow-up (action=flag). ISO 8601 with a time: \"2026-03-01T09:00:00Z\" or \"2026-03-01T09:00:00+10:00\" is that exact instant; \"2026-03-01T09:00:00\" (no zone) is read in the default timezone (OUTLOOK_DEFAULT_TIMEZONE)."
    • addedInput schema / properties / email
      Added value: +{
+  "description": "Alias for `sharedMailbox`.",
+  "type": "string"
+}
    • changedInput schema / properties / id / description
      Previous value: -"Single message ID (required for mark-read/mark-unread, or use instead of ids for flag actions)"New value: +"Single message ID (required for mark-read/mark-unread; flag actions take `id` or `ids`)"
    • addedInput schema / properties / sharedMailbox
      Added value: +{
+  "description": "Email address of the shared/delegated mailbox whose message(s) to update (default: the signed-in account). Requires delegate access + Mail.ReadWrite.Shared. Work/school only; needs the server opt-in setting OUTLOOK_SHARED_MAILBOX (otherwise the call is refused with setup guidance).",
+  "type": "string"
+}
    • changedInput schema / properties / startDateTime / description
      Previous value: -"Start date/time for follow-up, ISO 8601 (action=flag)"New value: +"Start date/time for follow-up (action=flag), same format as dueDateTime. Defaults to 09:00 on the due date in the default timezone (capped at the due time) when only dueDateTime is given."
  2. Changed1 schema field changedv3.7.4
    • addedInput schema / additionalProperties
      Added value: +false
  3. First observedv3.4.1

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: it explains why idempotency holds (safe to retry), that batch updates issue one PATCH per message rather than a Graph $batch, that unparseable or date-only times are refused before any change occurs, and it spells out auth/delegate prerequisites and the server opt-in setting. This is exactly the behavioral context annotations alone cannot convey.

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 front-loaded with the core guarantee ('update state without modifying content') and every subsequent sentence carries distinct, load-bearing detail. It is dense but somewhat long; a few clauses could be tightened, but nothing is filler.

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?

For a 7-parameter mutation tool with no output schema, it covers all the decision-relevant surface: per-action requirements, batch semantics, timezone edge cases, permission/opt-in prerequisites, and even the return shape ('a status per message'). An agent can invoke this correctly without further inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds semantics the schema does not: the timezone resolution rule for zoned vs unzoned ISO strings, the 09:00 default start (capped at the due time) when only `dueDateTime` is given, the `email` alias for `sharedMailbox`, and the single-vs-batch behavior of `id`/`ids`. These are genuine additions, not restatements.

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 names the exact operation and its boundary: 'Update message state without modifying content', which cleanly separates it from siblings like read-email, send-email, and draft. It then enumerates the concrete state transitions (read/unread, flag/unflag/complete), so an agent knows precisely what this tool touches.

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 maps each action to its purpose and states conditions: mark-read/mark-unread need a single `id`, flag/unflag/complete accept `id` or `ids`, and `sharedMailbox` is only for delegated mailboxes needing Mail.ReadWrite.Shared plus the OUTLOOK_SHARED_MAILBOX opt-in. It does not explicitly route the agent to a sibling (e.g. read-email for content), so usage context is clear but not fully comparative.

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