MS 365-21V MCP Server

List My Mail

mail_list_messages

Read-only

List Microsoft 365 emails newest first with filters for folder, time, unread, flagged, importance, or sender. Shows sender, recipients, preview, read and flag state.

Instructions

List mail newest first with sender, recipients, preview, read and flag state. Filter by folder (inbox by default, or all), time window, unread, flagged, importance or sender address. Use mail_search_messages for keywords. Requires delegated Mail.Read. Chinese intents / 中文意图: 查看我的邮件, 看最近邮件, 查看未读邮件, 查看标旗邮件, 某段时间的邮件, 列出收件箱邮件.

Input Schema

Name	Required	Description
`top`	No	Messages to return, from 1 to 50. Defaults to 20.
`from`	No	Only messages from this sender email address.
`since`	No	Received at or after this ISO date-time (China Standard Time if no offset).
`until`	No	Received before this ISO date-time.
`cursor`	No	nextCursor from the previous call.
`folder`	No	inbox (default), all, sentitems, drafts, deleteditems, archive, junkemail, or a folder ID.
`importance`	No	Only this importance.
`unreadOnly`	No	Only unread messages.
`flaggedOnly`	No	Only flagged (follow-up) messages.

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.2.0Oct 15, 2026

addedInput schema / properties / cursor

Added value: +{
+  "description": "nextCursor from the previous call.",
+  "maxLength": 4000,
+  "type": "string"
+}

addedInput schema / properties / flaggedOnly

Added value: +{
+  "description": "Only flagged (follow-up) messages.",
+  "type": "boolean"
+}

addedInput schema / properties / folder

Added value: +{
+  "description": "inbox (default), all, sentitems, drafts, deleteditems, archive, junkemail, or a folder ID.",
+  "maxLength": 300,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / from

Added value: +{
+  "description": "Only messages from this sender email address.",
+  "maxLength": 320,
+  "type": "string"
+}

addedInput schema / properties / importance

Added value: +{
+  "description": "Only this importance.",
+  "enum": [
+    "low",
+    "normal",
+    "high"
+  ],
+  "type": "string"
+}

addedInput schema / properties / since

Added value: +{
+  "description": "Received at or after this ISO date-time (China Standard Time if no offset).",
+  "maxLength": 40,
+  "type": "string"
+}

changedInput schema / properties / top / description

Previous value: -"Number of messages to return, from 1 to 50."New value: +"Messages to return, from 1 to 50. Defaults to 20."

changedInput schema / properties / unreadOnly / description

Previous value: -"Whether to return unread messages only."New value: +"Only unread messages."

addedInput schema / properties / until

Added value: +{
+  "description": "Received before this ISO date-time.",
+  "maxLength": 40,
+  "type": "string"
+}

First observedv0.1.0Aug 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds real context beyond them: the delegated Mail.Read auth scope and the default ordering (newest first). It also hints at return shape (sender, recipients, preview, read/flag state), though it does not mention pagination behavior implied by the cursor parameter.

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-loads what it does and what it returns, then the filters, then the alternative, and finally the auth requirement. The Chinese intent list is long but serves a concrete routing purpose for non-English queries; the rest is waste-free.

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?

With no output schema, the description still conveys the return fields, the default folder, ordering, auth scope, filter taxonomy, and the sibling alternative. Nothing an agent needs in order to call it correctly is missing.

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 100%, so the schema already documents all nine parameters with enums, defaults, and formats. The description groups the filter dimensions and restates the inbox default, which mirrors rather than extends the schema, so the baseline 3 is appropriate.

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 (List) and resource (mail), plus ordering (newest first) and the returned fields (sender, recipients, preview, read and flag state). It explicitly names the sibling it is not (mail_search_messages for keywords), so an agent can distinguish it without opening a schema.

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?

Enumerates the filter contexts (folder, time window, unread, flagged, importance, sender) that select this tool and routes keyword-based retrieval to mail_search_messages explicitly. The condition that governs the alternative is stated, not left to inference.

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

Deploy Server

List My Mail

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools