How do I use outlook-triage-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@outlook-triage-mcp Give me my daily briefing for the last 48 hours." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

outlook-triage-mcp

by giuseppeferretti

Overview Schema Related Servers Score Discussions

Python

Local

outlook-triage-mcp

MCP server for Microsoft 365 mail — search, classify, and triage your inbox from Claude via Microsoft Graph: daily-briefing digest, idempotent inbox-rule provisioning, attachment extraction. Device-code auth, read-only by default.

🇺🇸 English

Your inbox, triaged by Claude — without handing anyone your password. This MCP server connects Claude (Code or Desktop) to a Microsoft 365 mailbox through Microsoft Graph, using device-code sign-in and a local token cache. It classifies mail with deterministic keyword heuristics (no LLM calls at runtime, no message content leaving your machine beyond what you ask Claude to read), builds a morning briefing, and can — only if you explicitly opt in — provision inbox rules idempotently.

Features

Daily briefing — classifies the last N hours of inbox mail into urgent / action_needed / fyi / newsletter and renders a Markdown digest. Heuristics are deterministic and configurable (env vars or a JSON file); messages you already read are never flagged as pending.
Search & read — Graph $search/$filter message search in any folder; full plain-text bodies; local text extraction from PDF / DOCX / XLSX attachments (pypdf, python-docx, openpyxl — parsing is 100% local).
Idempotent inbox rules — ensure_inbox_rule converges mailbox state: an already-correct rule triggers zero write calls, a divergent one is patched, a missing one is created (folder included). Run it a hundred times, get one rule.
Device-code auth — MSAL public-client flow: the auth_status tool hands you a URL and a code; sign in from any browser. Tokens are cached in ~/.local/share/outlook-triage-mcp/ (never in the repo, 0600 permissions) and refreshed silently.
Read-only by default — the server requests only Mail.Read / MailboxSettings.Read scopes unless you set OUTLOOK_MCP_ENABLE_WRITE=1.
Retry/backoff — Graph calls honor Retry-After on 429 and back off exponentially on 5xx.

⚠️ Write access

ensure_inbox_rule is the ONLY tool that writes to your mailbox. Every other tool is strictly read-only (and annotated as such in the MCP tool metadata). Rule provisioning is disabled by default: the tool refuses to run until you start the server with OUTLOOK_MCP_ENABLE_WRITE=1 and re-authenticate with write scopes. The server never sends, deletes, moves, or marks messages.

Tools

Tool	Access	Description
`auth_status()`	read-only	Token state; starts device-code sign-in and returns the URL + code when login is needed
`search_messages(query, folder="inbox", top=20, since=None)`	read-only	Search (KQL) or list messages; `since` accepts ISO 8601 or relative (`24h`, `7d`)
`get_message(message_id, include_attachments=False)`	read-only	Full body + metadata; optionally extracts text from PDF/DOCX/XLSX attachments locally
`daily_briefing(hours=24)`	read-only	Markdown digest classified into urgent / action_needed / fyi / newsletter
`list_inbox_rules()`	read-only	Inventory of inbox rules with conditions and actions
`ensure_inbox_rule(name, from_contains, move_to_folder)`	WRITE	Idempotently converge one rule (sender contains X → move to folder Y); creates the folder if missing

Example prompts once connected:

"Give me my daily briefing for the last 48 hours." "Search my inbox for messages about the Q3 invoice and read the newest one, including attachments." "Make sure there's a rule moving everything from recruiting@ to a Recruiters folder." (requires write mode)

How it works

flowchart LR
    subgraph Claude["Claude (Code / Desktop)"]
        C[MCP client]
    end
    subgraph Server["outlook-triage-mcp (local)"]
        T[FastMCP tools]
        H[Heuristic classifier<br/>deterministic, no LLM]
        A[MSAL device-code auth<br/>token cache ~/.local/share]
        G[Graph client<br/>retry + backoff]
        X[Attachment extraction<br/>PDF / DOCX / XLSX, local]
    end
    M[(Microsoft Graph<br/>Microsoft 365 mailbox)]

    C <-->|stdio JSON-RPC| T
    T --> H
    T --> X
    T --> G
    G --> A
    G <-->|HTTPS, delegated scopes| M

Install

git clone https://github.com/giuseppeferretti/outlook-triage-mcp
cd outlook-triage-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[attachments]"    # attachments extra enables PDF/DOCX/XLSX parsing

Configure Claude

Claude Code:

claude mcp add outlook-triage -- /path/to/.venv/bin/outlook-triage-mcp

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "outlook-triage": {
      "command": "/path/to/.venv/bin/outlook-triage-mcp",
      "env": {
        "OUTLOOK_MCP_USER_EMAIL": "you@yourcompany.com"
      }
    }
  }
}

First use: ask Claude to call auth_status, open the verification URL it returns, type the code, done. The token is cached locally; you will rarely need to sign in again.

Configuration (env vars)

Variable	Default	Purpose
`OUTLOOK_MCP_CLIENT_ID`	Microsoft Graph CLI public client (`14d82eec-…`)	Azure AD app registration. The default is Microsoft's own Graph CLI public client, which is pre-authorized for delegated mail scopes on most tenants (the older Azure CLI client is blocked for `Mail.*` — AADSTS65002). If your tenant blocks it, register your own public-client app with device-code flow and delegated `Mail.Read` + `MailboxSettings.Read`, and set this variable.
`OUTLOOK_MCP_TENANT_ID`	`common`	Restrict sign-in to a specific tenant
`OUTLOOK_MCP_USER_EMAIL`	—	Your address; used to pick the cached account and to classify self-sent mail
`OUTLOOK_MCP_ENABLE_WRITE`	`0`	Set `1` to enable `ensure_inbox_rule` (requests write scopes on next sign-in)
`OUTLOOK_MCP_CACHE_DIR`	`~/.local/share/outlook-triage-mcp`	Token cache location
`OUTLOOK_MCP_CLASSIFY_FILE`	—	JSON file overriding heuristic keyword lists
`OUTLOOK_MCP_URGENT_KEYWORDS` / `OUTLOOK_MCP_ACTION_KEYWORDS` / `OUTLOOK_MCP_NEWSLETTER_SENDERS` / `OUTLOOK_MCP_NEWSLETTER_KEYWORDS` / `OUTLOOK_MCP_VIP_SENDERS`	built-in lists	Comma-separated overrides for individual heuristic lists
`OUTLOOK_MCP_MAX_ATTACHMENT_BYTES`	`5242880`	Attachments larger than this are listed, not parsed

Classification file example (classify.json):

{
  "urgent_keywords": ["urgent", "asap", "outage"],
  "action_keywords": ["please review", "sign off"],
  "vip_senders": ["ceo@yourcompany.com"],
  "newsletter_sender_patterns": ["noreply@", "digest@"]
}

Development

pip install -e ".[dev]"
pytest              # all offline: fixture JSON + fake Graph + stdio smoke test
OUTLOOK_MCP_LIVE_TESTS=1 pytest tests/test_graph_live.py   # optional, real Graph

The test suite requires no Microsoft account: classification and rule-idempotency tests run against fake Graph responses, and the MCP smoke test boots the real stdio server with the official SDK client and verifies the tool list and graceful auth-required behavior.

Provenance

This server was extracted from a production Microsoft 365 automation system — a daily-briefing robot and idempotent inbox-rule provisioner that runs every morning for a real controllership workflow. The battle-tested parts were kept (device-code auth with token cache, Graph retry/backoff, write-free classification, converge-don't-duplicate rule provisioning) and the client-specific heuristics were genericized into configurable keyword lists. Case study at portfolio.iterlabs.com.br.

Related MCP server: m365-mcp

🇧🇷 Português

Servidor MCP para e-mail Microsoft 365 — busque, classifique e faça triagem da sua caixa de entrada pelo Claude via Microsoft Graph. Autenticação por device-code (sem senha no servidor), token em cache local, somente leitura por padrão.

Recursos

Briefing diário: classifica as últimas N horas em urgent / action_needed / fyi / newsletter com heurísticas determinísticas (sem LLM em runtime), configuráveis por env ou arquivo JSON. Mensagens já lidas nunca aparecem como pendentes.
Busca e leitura: pesquisa Graph em qualquer pasta, corpo completo em texto e extração local de texto de anexos PDF / DOCX / XLSX.
Regras idempotentes: ensure_inbox_rule converge o estado da caixa — regra já correta gera zero chamadas de escrita; nunca duplica regra nem pasta.
Retry/backoff nas chamadas Graph (respeita Retry-After em 429).

⚠️ Escrita

ensure_inbox_rule é a ÚNICA ferramenta que escreve na caixa. Todas as outras são somente leitura. Escrita fica desabilitada até você definir OUTLOOK_MCP_ENABLE_WRITE=1 e autenticar novamente com escopos de escrita. O servidor nunca envia, exclui, move ou marca mensagens.

Instalação e uso

git clone https://github.com/giuseppeferretti/outlook-triage-mcp
cd outlook-triage-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[attachments]"
claude mcp add outlook-triage -- /caminho/para/.venv/bin/outlook-triage-mcp

No primeiro uso, peça ao Claude para chamar auth_status: ele devolve uma URL e um código — abra no navegador, digite o código e pronto. O token fica em cache em ~/.local/share/outlook-triage-mcp/ (nunca no repositório).

Configuração principal: OUTLOOK_MCP_CLIENT_ID (padrão: client público do Microsoft Graph CLI; registre seu próprio app se o tenant bloquear), OUTLOOK_MCP_TENANT_ID, OUTLOOK_MCP_USER_EMAIL, OUTLOOK_MCP_ENABLE_WRITE e as listas de palavras-chave OUTLOOK_MCP_*_KEYWORDS / OUTLOOK_MCP_VIP_SENDERS.

Testes: pytest roda 100% offline (fixtures JSON + Graph falso + smoke test MCP stdio com o SDK oficial). Testes contra o Graph real são opcionais: OUTLOOK_MCP_LIVE_TESTS=1.

Origem

Extraído de um sistema de automação Microsoft 365 em produção (robô de briefing diário + provisionamento idempotente de regras), com as heurísticas do cliente genericizadas em listas configuráveis. Case em portfolio.iterlabs.com.br.

Built with AI-assisted development; designed, verified, and operated by Giuseppe Ferretti.

Available Tools

6 tools

auth_statusA

Read-only

Check Microsoft 365 auth state; start device-code sign-in if needed.

When sign-in is required, returns a verification URL and a user code — relay both to the user, then call this tool again to confirm completion.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Adds context beyond readOnlyHint annotation: describes the sign-in flow and user interaction. No contradiction, but the annotation's readOnlyHint might imply no side effects, while description mentions starting sign-in. However, it's not a clear contradiction.

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?

Two efficient sentences, front-loaded with main action, then procedural detail. No wasted words.

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?

Complete for a zero-parameter, no-output-schema tool. Description explains behavior and user steps adequately.

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?

No parameters, so baseline is 4. Description fully covers the zero-parameter need without redundancy.

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?

The description clearly states the tool checks Microsoft 365 auth state and initiates sign-in if needed. It is specific and distinguishes from sibling tools (all related to email/messaging).

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?

The description explains when to use (check auth or start sign-in) and instructs to call again after relaying credentials. It lacks explicit exclusions or alternatives but context makes it clear.

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

daily_briefingA

Read-only

Classified digest of recent inbox mail. Read-only, no LLM calls.

Groups messages from the last N hours into: urgent, action_needed, fyi, newsletter — using deterministic keyword heuristics (configurable via OUTLOOK_MCP_* env vars or a JSON rules file). Returns Markdown.

ParametersJSON Schema

Name	Required	Description	Default
`hours`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description details the grouping method, configurability via env vars or JSON file, and output format (Markdown). No contradictions.

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?

The description is very concise and front-loaded with the main purpose. Every sentence adds value, no waste.

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?

Given one optional parameter and the presence of an output schema (Markdown), the description covers purpose, behavior, configuration, and return format comprehensively.

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?

The description mentions 'messages from the last N hours' indirectly describing the 'hours' parameter, but does not explicitly define it. With 0% schema coverage, the description partially compensates but lacks direct parameter documentation.

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?

The description clearly states it provides a 'classified digest of recent inbox mail' and groups messages into categories. It distinguishes itself from siblings like search_messages and get_message by serving as a summary tool.

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?

The description implies usage for a quick overview of recent emails with 'Read-only, no LLM calls' indicating safety. However, it does not explicitly contrast with sibling tools or provide when-not-to-use guidance.

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

ensure_inbox_ruleA

Idempotent

Idempotently provision one inbox rule. THE ONLY WRITE TOOL.

Creates (or converges) a rule: messages whose sender matches from_contains are moved to folder move_to_folder (created if missing). Safe to run repeatedly — an already-correct rule results in zero write calls; never duplicates rules or folders.

Disabled unless the server runs with OUTLOOK_MCP_ENABLE_WRITE=1 (which also requires re-consenting to write scopes on next sign-in).

Args: name: Rule display name — the idempotency key. from_contains: Substring matched against the sender address/name. move_to_folder: Target folder display name.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`from_contains`	Yes
`move_to_folder`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate idempotent and non-destructive. The description adds details: 'zero write calls if already correct', 'never duplicates rules or folders', and the write-enablement condition. This enriches understanding beyond annotations.

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 description is concise and well-structured, with a bold introductory statement followed by details. The Args block is efficiently formatted. Minor redundancy with 'THE ONLY WRITE TOOL' emphasis, but overall effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple operation with 3 params and no output schema, the description covers purpose, idempotency, and enablement condition. However, it lacks information about error handling, return values, or what happens if the folder creation fails. This is adequate but not fully 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?

Even though schema description coverage is 0%, the description provides an Args block with clear explanations: name as idempotency key, from_contains as substring match, move_to_folder as target folder. This fully compensates for the schema's lack of descriptions.

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?

The description clearly states the tool's function: 'Idempotently provision one inbox rule' and explains it moves messages matching 'from_contains' to 'move_to_folder'. It also distinguishes itself as 'THE ONLY WRITE TOOL' among siblings, establishing clear identity.

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?

The description explains idempotency and safety of repeated runs, and notes the environment variable requirement for enablement. However, it does not explicitly compare against sibling tools like 'list_inbox_rules' or provide when-not-to-use guidance, though the 'only write tool' hint provides context.

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

get_messageA

Read-only

Fetch one message: full plain-text body plus metadata. Read-only.

Args: message_id: Graph message id (from search_messages or daily_briefing). include_attachments: Also download attachments and extract text locally from PDF / DOCX / XLSX (other types are listed only).

ParametersJSON Schema

Name	Required	Description	Default
`message_id`	Yes
`include_attachments`	No

TDQS

A4.7/5.0

Behavior5/5

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

The description adds behavioral context beyond the readOnlyHint annotation, including that it retrieves plain-text body and metadata, and details the include_attachments behavior (download and extract text locally for PDF/DOCX/XLSX, list others).

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?

The description is concise: two sentences front-loading the purpose and read-only nature, followed by clear parameter explanations. No redundant information.

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?

The description covers both parameters and key behaviors. However, it does not specify what 'metadata' includes, and there is no output schema. Still, it is sufficient for use given the tool's simplicity.

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?

Despite 0% schema coverage, the description explains both parameters: message_id as a Graph message id from specific sources, and include_attachments with details on extraction behavior. This adds crucial meaning beyond the schema types.

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?

The description clearly states the tool's purpose: 'Fetch one message: full plain-text body plus metadata. Read-only.' It distinguishes from sibling tools like search_messages (which retrieves multiple messages) and daily_briefing (a summary).

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?

The description indicates the tool is for fetching a single message and mentions where to obtain the message_id ('from search_messages or daily_briefing'). However, it does not explicitly state when not to use it or provide direct comparisons to siblings.

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

list_inbox_rulesA

Read-only

List all inbox message rules (name, state, conditions, actions). Read-only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already include readOnlyHint=true; description adds that it returns name, state, conditions, actions. Provides some context beyond annotations but not critical.

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?

Two sentences, front-loaded with verb and resource, no fluff. Efficient and focused.

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 zero-parameter read-only tool, the description fully explains its purpose and output fields. No output schema needed; sibling tools provide context.

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?

No parameters, schema coverage 100%. Description adds no parameter info, which is appropriate. Baseline 4 for zero-param tool.

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?

Clear verb 'List', specific resource 'inbox message rules', and explicit listing of returned fields (name, state, conditions, actions). Distinct from sibling tools like ensure_inbox_rule and search_messages.

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?

States 'Read-only', implying safety. Context of sibling tools (e.g., ensure_inbox_rule) makes usage clear, but no explicit when-not guidance.

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

search_messagesA

Read-only

Search or list mail messages. Read-only.

Args: query: Free-text search (Graph $search / KQL, e.g. 'invoice', 'from:alice subject:report'). Empty = list newest first. folder: Well-known folder (inbox, archive, drafts, sentitems, deleteditems, junkemail, outbox) or a custom folder display name. top: Max messages to return (1-100). since: Only messages received after this point. ISO 8601 ('2026-07-01T00:00:00Z') or relative ('24h', '7d').

ParametersJSON Schema

Name	Required	Default
`top`	No
`query`	No
`since`	No
`folder`	No	inbox

TDQS

A4.9/5.0

Behavior5/5

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

The description explicitly says 'Read-only', consistent with annotations. It details query behavior (free-text search, KQL), folder types, date range formats, and max messages. No contradictions with annotations; adds significant behavioral context.

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?

The description is a well-structured docstring with a clear one-line purpose followed by a bulleted parameter list. Every sentence provides value; no redundancy. It is appropriately concise for the complexity.

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?

Given no output schema, the description could mention return fields (e.g., message metadata). It explains inputs thoroughly but omits output structure. Still, it covers core functionality well for most use cases.

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?

With 0% schema description coverage, the description fully explains each parameter: query (KQL search), folder (well-known or custom), top (1-100), since (ISO 8601 or relative). This adds essential meaning beyond the schema's default values.

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?

The description starts with 'Search or list mail messages. Read-only.' which clearly states the action (search/list) and resource (mail messages). It distinguishes itself from siblings like get_message (single message) and list_inbox_rules (rules management).

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?

The description explains that an empty query lists messages, provides example KQL syntax, and mentions folder restrictions. It implicitly tells when to use this tool vs siblings (e.g., not for a specific message). The 'Read-only' note clarifies it's safe.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jul 6, 2026
- First observedauth_status
- First observeddaily_briefing
- First observedensure_inbox_rule
- First observedget_message
- First observedlist_inbox_rules
- First observedsearch_messages

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clear and distinct purpose: auth_status for authentication, daily_briefing for digest, ensure_inbox_rule for rule creation, get_message for fetching a single message, list_inbox_rules for listing rules, and search_messages for searching. No two tools overlap in functionality.

Naming Consistency3/5

While most names follow a verb_noun pattern (e.g., ensure_inbox_rule, get_message), some deviate: daily_briefing is a noun phrase, and auth_status is noun_noun. This inconsistency, though not severe, prevents a higher score.

Tool Count5/5

Six tools is an appropriate scope for an Outlook triage server, covering authentication, inbox digest, rule management, message retrieval, rule listing, and message search. None seem redundant or missing for the stated purpose.

Completeness3/5

The server covers reading (search, get, digest) and rule creation, but lacks message actions (delete, move, mark as read) and rule deletion. This is a notable gap for a triage tool, as users cannot act on individual messages beyond reading.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

nylas A
io.usefulapi
MCP server for Nylas — read email, calendars, events and contacts, and send email or create events.
Email Calendar Management CRM
152
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
Agent Safe AOAuth
io.github.wowcool
Email safety MCP server. Detects phishing, prompt injection, CEO fraud for AI agents.
Security Autonomous Agents
2
email A
dev.primitive
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email Communication
302

Related MCP Servers

Outlook Assistant
Calendar Management Communication Workplace & Productivity
titanzero
A
license
A
quality
D
maintenance
MCP server for Claude to access Outlook data via Microsoft Graph API
Updated 3 months ago (2026-06-13 19:14 UTC)
20
114
1
MIT
m365-mcp
Communication Workplace & Productivity Cloud Storage
Corvalon
A
license
Not graded
quality
C
maintenance
A Model Context Protocol server that gives Claude Code (or any MCP client) controlled access to Microsoft 365 through the Microsoft Graph API: mail, calendar, contacts, files, notes, tasks, Teams, SharePoint, and the full tenant-admin surface.
Updated 3 days ago (2026-09-03 23:17 UTC)
39
1
MIT
outlook-mcp
Email Communication
hamzashahbaz
A
license
Not graded
quality
D
maintenance
MCP server that enables Claude to manage Outlook emails, including reading, sending, organizing, drafting, and bulk operations via Microsoft Graph API.
Updated 5 months ago (2026-03-29 21:43 UTC)
15
1
MIT
hotmail-mcp
Email Security
oshann
A
license
A
quality
C
maintenance
A local MCP server that connects Claude Desktop to a personal Hotmail/Outlook.com mailbox via Microsoft Graph API, enabling email management, rule handling, and composing messages.
Updated a month ago (2026-07-28 09:30 UTC)
25
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/giuseppeferretti/outlook-triage-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server