Skip to main content
Glama
Outlook MCP Server

Outlook MCP Server

by kennymatsudo

create_rule

Creates a server-side Outlook inbox rule to sort incoming mail automatically, enabling future messages to be moved, categorized, marked read, or sent to Deleted Items without the server running.

Instructions

Create a server-side inbox rule so future mail is sorted without this server running. Check list_rules first to avoid a duplicate.

Conditions are OR-ed within a field and AND-ed across fields, as Outlook evaluates them. At least one condition and one action are required. from_addresses: exact sender addresses. sender_contains: substring of the From field, which catches a whole domain. move_to: a well-known folder name or a folder id from list_folders / create_folder. delete_to_deleted_items sends matches to Deleted Items; nothing is permanently deleted, and forwarding rules are not supported. A rule applies only to mail arriving from now on; use archive_matching or the other cleanup tools for mail already in the mailbox.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "create_rule"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
enabledNo
move_toNo
sequenceNo
mark_as_readNo
body_containsNo
from_addressesNo
has_attachmentsNo
header_containsNo
sender_containsNo
stop_processingNo
subject_containsNo
assign_categoriesNo
delete_to_deleted_itemsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations the description carries the full burden and does well: it discloses persistence scope (future mail only), that nothing is permanently deleted, that forwarding is unsupported, and the OR/AND evaluation model plus the at-least-one-condition-and-one-action constraint. It does not cover what happens on name collision, permission requirements, or the effect of the enabled/stop_processing flags, which are meaningful behavioral gaps for a rule engine.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads what the tool does and the duplicate check, then groups constraints, then parameter notes, then scope limits. No filler sentences and no repetition of the input schema.

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 14-parameter mutation tool with zero annotation and zero schema-description support, this is substantially complete on the matching model and scope limits. The remaining gaps are the ordering/stop-processing semantics and error/return behavior, which matter given sequence and stop_processing default to true.

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 description coverage is 0% across 14 parameters, so the description must compensate. It adds real meaning for from_addresses (exact addresses), sender_contains (substring matching, catches a domain), move_to (folder name or id from list_folders/create_folder), and delete_to_deleted_items, but leaves stop_processing, sequence, enabled, and several condition fields (header_contains, subject_contains, body_contains) without explanation beyond their titles.

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?

States a specific verb and resource ('Create a server-side inbox rule') and immediately adds the differentiator that it runs server-side so sorting persists without this server. That distinguishes it cleanly from client-side cleanup siblings like archive_matching or move_messages.

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 says to check list_rules first to avoid duplicates, and explicitly routes existing-mail cleanup elsewhere ('use archive_matching or the other cleanup tools for mail already in the mailbox'). It also names a non-supported capability (forwarding) so the agent does not attempt it here.

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