outlook-local-mcp

Overview Schema Source Related Servers Discussions Admin

search_emails

Read-only

Find emails in a local Outlook folder using literal text and filters like sender, date, or attachment. Returns metadata; reads bodies only when needed.

Instructions

Search one folder without recursion, newest received first. query is a literal substring, not Outlook AQS/OR/NOT syntax. Call directly for the default Inbox, with no mailbox/folder discovery prerequisite. Return metadata first, and read bodies only when the user's question requires them. Text matching is a case-insensitive substring in subject, body, or subject_body; sender matches the name or available SMTP address. All filters combine with AND. recipient matches available recipient names/SMTP addresses; attachment_name matches attachment filenames. category matches a complete category name; importance accepts low, normal or high. Text matching is case-insensitive. after is inclusive; before is exclusive. Dates accept YYYY-MM-DD at Windows local midnight or ISO 8601 with timezone. Body search reads bodies explicitly. Each call examines at most 1000 candidates for about 10 seconds; an external 30-second deadline protects against blocked Outlook. IMPORTANT: zero items with coverage.exhausted=false is an unfinished search, not proof that no email matches. Follow next_cursor with identical filters, optionally changing limit. Cursors are single-use, expire after 10 minutes, and are lost on worker restart. evaluation_complete also accounts for inaccessible candidates; results are best effort.

Input Schema

TableJSON Schema

Name	Required	Default
`after`	No
`limit`	No
`query`	No
`before`	No
`cursor`	No
`sender`	No
`unread`	No
`category`	No
`query_in`	No	subject
`store_id`	No
`folder_id`	No
`recipient`	No
`importance`	No
`attachment_name`	No
`has_attachments`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`items`	Yes
`omitted`	No
`coverage`	Yes
`store_id`	Yes
`warnings`	No
`folder_id`	Yes
`next_cursor`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.2.1Sep 12, 2026

addedInput schema / properties / attachment_name

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 4096,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Attachment Name"
+}

addedInput schema / properties / category

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 4096,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Category"
+}

addedInput schema / properties / importance

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "low",
+        "normal",
+        "high"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Importance"
+}

addedInput schema / properties / recipient

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 4096,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Recipient"
+}

addedOutput schema / $defs / EmailSummary / properties / categories

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Categories"
+}

addedOutput schema / $defs / EmailSummary / properties / conversation_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Conversation Id"
+}

addedOutput schema / $defs / EmailSummary / properties / importance

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "low",
+        "normal",
+        "high"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Importance"
+}

First observedv0.1.0Sep 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes far beyond the readOnly/openWorld annotations: discloses the 1000-candidate / ~10s per-call cap, the external 30s deadline, the critical distinction that zero results with coverage.exhausted=false is not proof of absence, cursor single-use/10-min expiry/restart loss, and that evaluation_complete accounts for inaccessible candidates. This is exactly the operational context an agent needs and cannot derive from annotations.

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

Conciseness3/5

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

Front-loaded well with scope, query semantics, and the no-discovery note, plus the IMPORTANT callout is appropriately prominent. However it runs long and dense (repeated 'text matching is case-insensitive', layered filter and date explanations), and several clauses could be consolidated. Functional but not tight.

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?

For a 15-param, zero-required-param, open-world, non-idempotent search with an output schema, this covers intent, all filter semantics, pagination/cursor lifecycle, and the crucial exhausted/coverage reliability caveat. Return values are handled by the output schema, so the description is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry full parameter meaning and does: it defines query as literal substring (not AQS), subject/body/subject_body matching scope, sender/recipient name-or-SMTP matching, attachment_name on filenames, category as complete name, importance values, inclusive 'after'/exclusive 'before', and accepted date formats. It even explains cursor semantics for next_cursor. Comprehensive compensation for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (search emails) and a scope constraint ('one folder without recursion, newest received first'). Doesn't explicitly name siblings like recent_emails or list_folders, but the folder/recursion constraint and the 'no mailbox/folder discovery prerequisite' line distinguish it functionally. Clear enough to select without opening the schema.

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

Usage Guidelines4/5

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

Tells the agent to call directly for the default Inbox with no discovery prerequisite, and to return metadata first and read bodies only when needed (pointing toward read_email as the alternative). Doesn't explicitly enumerate when NOT to use it vs. recent_emails or read_conversation, but the usage context is concrete and actionable.

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

Deploy Server