Outlook MCP Server

Overview Schema Source Related Servers Discussions Admin

unsubscribe

Stops future email from approved senders using each sender’s latest message; previews first, then acts only after you confirm the exact sender list.

Instructions

Unsubscribe from senders the user has approved, using each sender's latest message in folder. senders: addresses from find_unsubscribable.

Without confirm_count this only previews the method per sender and changes nothing. Call again with confirm_count equal to the number of senders (max 25), and only after the user approved that exact list. Uses RFC 8058 one-click where the sender supports it, otherwise Outlook's mailto method, which also moves that one message to Deleted Items. Senders that fail authentication, sit in Junk or offer only a web page are reported and never acted on. Existing mail from these senders is untouched.

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": {
      "senders": "<senders>"
    },
    "name": "unsubscribe"
  }
}

Input Schema

Name	Required	Default
`folder`	No	inbox
`senders`	Yes
`confirm_count`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A4.7/5.0

Behavior5/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 so: it discloses the preview/confirm gate, the 25-sender cap, the two unsubscribe mechanisms (RFC 8058 one-click vs Outlook mailto), the side effect that the mailto path moves one message to Deleted Items, failure reporting, and that existing mail is untouched.

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 core action and the preview/confirm distinction are front-loaded, and each subsequent sentence adds a distinct constraint (cap, mechanisms, exceptions, untouched mail). The RFC 8058/mailto sentence is dense but earns its length by explaining a side effect.

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 destructive, multi-sender tool with no annotations and no output schema, this covers safety gating, side effects, and failure modes well. It does not describe what the preview response looks like or how failures are enumerated, a minor remaining gap.

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 0%, so the description must compensate, and it largely does: senders are addresses from find_unsubscribable, folder selects which message's sender set is used, and confirm_count governs preview vs. execution with a stated maximum. The folder default ('inbox') and the exact preview output are not restated, leaving a small gap.

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 (unsubscribe) and resource (senders), scopes it to 'senders the user has approved' using 'each sender's latest message in folder', and names the source tool find_unsubscribable, distinguishing it from siblings like send_draft or delete_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 defines the two-step protocol: without confirm_count it only previews and changes nothing; with confirm_count equal to the number of senders (max 25) it acts, and only after the user approved that exact list. It also names the prerequisite tool and the cases that will not be acted on (auth failure, Junk, web-page-only).

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