Skip to main content
Glama
littlebearapps

Outlook Assistant

by littlebearapps
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Apply Categories

apply-category
Idempotent

Tag or untag Outlook emails with master categories by setting, adding, or removing labels on single or batch messages, including shared mailboxes.

Instructions

Tag or untag email messages with master categories (those created via manage-category). action=set (default) replaces the message's category set with the supplied categories array. action=add appends categories to whatever's already on the message. action=remove removes only the named categories, leaving the rest. Accepts either messageId (single) or messageIds (batch: one request per message). categories are matched by display name — names must already exist in the target mailbox's master list. For your own mailbox, create them via manage-category first; for a shared mailbox, the names must already exist there (manage-category only manages the signed-in account's master list). Pass sharedMailbox (or alias email) to categorise messages in a shared/delegated mailbox (default: the signed-in account; requires Mail.ReadWrite.Shared + delegate access). Returns per-message confirmation.

Input Schema

NameRequiredDescriptionDefault
emailNoAlias for `sharedMailbox`.
actionNoset (replace all), add (append), remove (remove specific). Default: set
messageIdNoSingle message ID to categorise
categoriesYesCategory display names to apply/remove (required)
messageIdsNoArray of message IDs to categorise (batch operation)
sharedMailboxNoEmail address of the shared/delegated mailbox whose messages to categorise (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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.14.1
    • addedInput schema / properties / email
      Added value: +{
+  "description": "Alias for `sharedMailbox`.",
+  "type": "string"
+}
    • addedInput schema / properties / sharedMailbox
      Added value: +{
+  "description": "Email address of the shared/delegated mailbox whose messages to categorise (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"
+}
  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.5/5.0
Behavior4/5

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

Annotations already declare the safety profile (not read-only, idempotent, non-destructive), so the bar is lower. The description adds real context beyond them: categories must pre-exist in the mailbox's master list, shared mailbox use requires Mail.ReadWrite.Shared + delegate access and the OUTLOOK_SHARED_MAILBOX opt-in, and it confirms per-message return output. Loses a point for not clarifying error/partial-failure behavior on batch operations.

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?

Dense but well-organized; the core purpose leads, followed by action semantics, then prerequisites. Each sentence carries information, though the category-creation prerequisites (manage-category before shared mailbox caveats) are slightly repetitive and could be tightened.

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 6-param mutation tool with no output schema, the description covers action semantics, batch vs single, prerequisites, permissions, and return format. It is nearly complete, with only edge-case behavior (e.g., what happens on invalid category names) left unspecified.

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 baseline is 3. The description goes beyond the schema by explaining that `categories` are matched by display name and must already exist in the target mailbox, that `sharedMailbox`/`email` are aliases, and that batch yields one request per message — meaningful semantics not captured in the enum/field descriptions.

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?

Opens with a specific verb and resource ('Tag or untag email messages with master categories') and immediately scopes it to the master list created via `manage-category`, cleanly separating it from that sibling. An agent can tell this applies categories to messages rather than managing the category list itself.

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

Usage Guidelines5/5

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

Explicitly distinguishes the three `action` modes (set replaces, add appends, remove removes only named), explains single vs batch via `messageId`/`messageIds`, and states when to use `sharedMailbox`/`email`. It also routes the agent to `manage-category` for creating categories and warns that it won't work for shared mailboxes.

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