outlook-mcp

outlook_list_inbox

Read-only

Lists messages in a chosen Outlook folder with filters for unread status, sender, date, category, and Focused inbox, supporting folder-scoped browsing and targeted message retrieval.

Instructions

List messages in one folder with structured filters (read, sender, date, category, Focused).

Use this for folder-scoped browsing; use outlook_search_mail for KQL full-text search across all folders. For polling/recurring agents use outlook_list_inbox_delta (typically 10x cheaper after the first call).

Example: outlook_list_inbox(folder="Junk Email", unread_only=True, count=5) folder accepts display names, well-known names ("inbox", "junkemail"), or Graph IDs — prefer names. Pass concise=True to drop large fields (preview, categories) — ~10x fewer tokens. Pass uncategorized_only=True to return only messages with no categories assigned. after/before take ISO 8601 or a relative offset — 7d is seven days ago, +7d is seven days from now.

Input Schema

Name	Required	Default
`skip`	No
`after`	No
`count`	No
`before`	No
`cursor`	No
`folder`	No	inbox
`concise`	No
`unread_only`	No
`from_address`	No
`classification`	No
`uncategorized_only`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed27 schema fields changedv1.30.2Oct 30, 2026
- removedInput schema / properties / after / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / after / default
```
Removed value: -null
```
- removedInput schema / properties / after / title
```
Removed value: -"After"
```
- addedInput schema / properties / after / type
```
Added value: +"string"
```
- removedInput schema / properties / before / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / before / default
```
Removed value: -null
```
- removedInput schema / properties / before / title
```
Removed value: -"Before"
```
- addedInput schema / properties / before / type
```
Added value: +"string"
```
- removedInput schema / properties / classification / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / classification / default
```
Removed value: -null
```
- removedInput schema / properties / classification / title
```
Removed value: -"Classification"
```
- addedInput schema / properties / classification / type
```
Added value: +"string"
```
- removedInput schema / properties / concise / title
```
Removed value: -"Concise"
```
- removedInput schema / properties / count / title
```
Removed value: -"Count"
```
- removedInput schema / properties / cursor / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / cursor / default
```
Removed value: -null
```
- removedInput schema / properties / cursor / title
```
Removed value: -"Cursor"
```
- addedInput schema / properties / cursor / type
```
Added value: +"string"
```
- removedInput schema / properties / folder / title
```
Removed value: -"Folder"
```
- removedInput schema / properties / from_address / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / from_address / default
```
Removed value: -null
```
- removedInput schema / properties / from_address / title
```
Removed value: -"From Address"
```
- addedInput schema / properties / from_address / type
```
Added value: +"string"
```
- removedInput schema / properties / skip / title
```
Removed value: -"Skip"
```
- removedInput schema / properties / uncategorized_only / title
```
Removed value: -"Uncategorized Only"
```
- removedInput schema / properties / unread_only / title
```
Removed value: -"Unread Only"
```
- removedInput schema / title
```
Removed value: -"outlook_list_inboxArguments"
```
Addedv1.14.0Sep 7, 2026
Removedv1.12.0Jul 19, 2026
First observedv1.11.0Jun 10, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real behavioral value beyond that — concise=True drops preview/categories for ~10x fewer tokens, uncategorized_only filters to uncategorized messages, and relative date offsets are spelled out. It does not explain pagination semantics (skip vs cursor) or what the result envelope looks like, which keeps it short of a 5.

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-loaded with purpose, then routing, then parameter guidance, then a concrete example. Every sentence carries distinct information; the token-cost and date-format tips are compactly stated with no filler.

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 an 11-param read tool with no output schema and no annotation detail beyond readOnlyHint, the definition covers routing, the trickiest parameters, and a token-saving mode. It stops short on pagination (cursor/skip interplay) and on what a returned message contains beyond the mention of preview/categories fields.

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?

With 0% schema description coverage the description carries the full burden, and it delivers for the highest-value params: folder accepts display names, well-known names, or Graph IDs (prefer names), after/before accept ISO 8601 or relative offsets like `7d`/`+7d`, plus concise and uncategorized_only semantics, with a worked example showing unread_only and count. Four params — skip, cursor, from_address, and classification — get no explanation at all, which is the remaining 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?

Starts with a specific verb+resource ('List messages in one folder') and immediately scopes the filter set (read, sender, date, category, Focused). It explicitly distinguishes itself from sibling tools outlook_search_mail and outlook_list_inbox_delta, so an agent can route 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?

Gives explicit when-to-use routing: folder-scoped browsing here, KQL full-text via outlook_search_mail, polling/recurring via outlook_list_inbox_delta with a concrete cost rationale (10x cheaper after first call). Alternatives and the condition selecting each are named, not implied.

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

Deploy Server

outlook_list_inbox

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools