MCP server for local Outlook email RAG search with semantic embeddings and attachment parsing
Server has 8 tools with complete input schemas and descriptions present for all tools and parameters. Naming follows verb_noun convention (search_emails, get_email, list_folders, rebuild_index). However, descriptions are generic and lack LLM-optimization guidance. Parameter descriptions are minimal (10-30 chars typically). No output schemas documented. Error handling is absent from tool definitions. Missing tool annotations (readOnlyHint, destructiveHint). Composition is reasonable but rebuild_index and refresh_index could benefit from clearer state-mutation warnings.
Check Outlook connection status and account information
Retrieve full details of a specific email by entry ID
Get current status of the email index including counts and last update time
List all available Outlook mail folders
Rebuild the email index from scratch, clearing existing data and re-indexing all emails and attachments
Incrementally refresh the email index with new emails only (fast, skips attachment parsing)
Search attachment content by semantic similarity
No output schemas documented. LLMs cannot plan downstream calls or extract required fields (e.g., what does search_emails return? Does it include entry_id for get_email chaining?). Baseline: 100% of A+ tools document return types.
Destructive tools (rebuild_index, refresh_index) lack tool annotations and confirmation guidance. No dry-run or confirmation step documented. Agents may accidentally trigger full re-indexing without understanding consequences.
Parameter descriptions are minimal (10-30 chars). E.g., 'Filter by sender name (partial match, optional)' lacks guidance on format or examples. Baseline: avg param annotation 72 chars. LLMs need richer context to avoid invalid inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Search emails by semantic similarity with optional filtering by sender, date range, and folder
No error handling guidance in tool definitions. If search_emails returns no results or Outlook is disconnected, LLMs have no recovery path documented. Baseline: error responses must guide next steps.
Tool descriptions lack WHEN-to-use guidance. E.g., search_emails vs search_attachments distinction is unclear. When should an LLM choose one over the other? Descriptions should answer: What does it do? When to use it instead of similar tools?