Outlook MCP Server

Ein Model Context Protocol-Server, der Claude mit Microsoft Outlook + Teams verbindet (E-Mail, Kalender, Kontakte, Aufgaben, Dateien, Teams-Besprechungsaufzeichnungen + Transkripte), bereitgestellt auf Cloudflare Workers.

Forken Sie dieses Repository, stellen Sie es auf Ihrem eigenen Cloudflare-Konto bereit, registrieren Sie eine Microsoft Azure AD-App, richten Sie Claude.ai auf Ihren Worker aus, und Claude kann Ihre Microsoft 365-Daten über natürliche Sprache lesen und schreiben.

Basiert auf @bashco/mcp-toolkit – OAuth, Bearer-Tokens pro Client, Ratenbegrenzung, strukturierte Protokollierung und typisierte Tool-Verteilung werden alle von der gemeinsamen Bibliothek übernommen.

Was Claude bekommt – 39 Tools in 7 Bereichen

• E-Mail: E-Mails auflisten, E-Mail lesen, suchen, antworten, weiterleiten, löschen, senden, zwischen Ordnern verschieben, Entwurf erstellen, Entwurf aktualisieren, Entwurf senden, geplantes Senden

• Kalender: Ereignisse auflisten, Ereignisvorkommen auflisten, erstellen, aktualisieren, löschen, Ereignis abbrechen, auf Ereignis antworten

• Kontakte: auflisten, Kontakt erstellen, Kontakt aktualisieren

• Aufgaben: Aufgabenlisten auflisten, Aufgaben auflisten, Aufgabe erstellen

• Dateien: Dateien auflisten, Datei teilen

• Teams-Besprechungen: aktuelle Aufzeichnungen auflisten (der Ausgangspunkt für die Erkennung – findet Besprechungen mit Inhalten in den letzten N Tagen, keine Eingaben erforderlich), Online-Besprechung finden, Besprechungsaufzeichnungen auflisten, Besprechungstranskripte auflisten, Transkriptinhalt abrufen. Jedes besprechungsbezogene Tool akzeptiert meeting_id, calendar_event_id oder join_url – so funktionieren geplante Besprechungen (über Ereignis aufgelöst), Ad-hoc-/Meet-now-Anrufe (über die aus dem Teams-Chat eingefügte Join-URL aufgelöst) und direkte ID-Suchen.

• Unterhaltung: Unterhaltung abrufen (vollständiger Thread)

• Einstellungen: Postfacheinstellungen abrufen, Abwesenheit festlegen

Vollständiger Live-Katalog am MCP-Endpunkt tools/list nach der Bereitstellung.

Related MCP server: MCP Outlook Server

So funktioniert die Authentifizierung

Zwei Ebenen:

1. Claude.ai ↔ Ihr Worker – Standard-MCP-OAuth-2.0- und PKCE-Ablauf. Jeder Claude-Client erhält ein eindeutiges Bearer-Token; Ihr MCP_APPROVAL_CODE ist das, was Sie einmal unter /authorize einfügen, um dieses Bearer-Token zu erzeugen.

2. Ihr Worker ↔ Microsoft Graph – proxied OAuth. Sie autorisieren Microsoft einmal, indem Sie /oauth/start auf Ihrem bereitgestellten Worker besuchen; Aktualisierungstokens werden verschlüsselt in Cloudflare KV gespeichert. Die Aktualisierung erfolgt automatisch.

Einrichtung – Stellen Sie Ihre eigene Kopie bereit

Voraussetzungen

• Ein Cloudflare-Konto (kostenloser Plan funktioniert)

• Wrangler-CLI installiert und angemeldet (wrangler login)

• Node.js 22+

• Ein Microsoft-Konto (privat, geschäftlich oder schulisch) mit Zugriff zur Registrierung von Azure-AD-Apps unter entra.microsoft.com

1. Forken und klonen

git clone https://github.com/<your-username>/outlook-mcp
cd outlook-mcp
npm install

2. Den KV-Namespace erstellen

wrangler kv:namespace create OAUTH_KV

Wrangler gibt etwa Folgendes aus:

🌀 Creating namespace with title "outlook-mcp-OAUTH_KV"
✨ Success! Add the following to your configuration file:
[[kv_namespaces]]
binding = "OAUTH_KV"
id = "abc123def456..."

wrangler.jsonc ist absichtlich eingecheckt – sowohl Wrangler als auch die CI-Bereitstellung benötigen es, und es enthält keine Geheimnisse (nur Ihre KV-Namespace-ID, die öffentliche Azure-Client-ID und die Worker-URL). wrangler.jsonc.example hat dieselbe Struktur mit Platzhaltern, falls Sie lieber mit einer sauberen Kopie beginnen möchten. Echte Geheimnisse werden über wrangler secret put gesetzt und erscheinen nie in dieser Datei.

3. Eine Microsoft Azure AD-App registrieren

1. Gehen Sie zu entra.microsoft.com → Identity → Applications → App registrations → New registration

2. Name: beliebig (z. B. „Claude Outlook MCP")

3. Unterstützte Kontotypen:

   • „Nur Konten in diesem Organisationsverzeichnis", wenn Sie auf einen Mandanten beschränken möchten

   • „Konten in einem beliebigen Organisationsverzeichnis und persönliche Microsoft-Konten" für die breiteste Unterstützung

4. Redirect-URI: vorerst leer lassen – Sie kommen nach Schritt 6 zurück

5. Klicken Sie auf Registrieren

6. Notieren Sie auf der Übersichtsseite der App:

   • Anwendungs-ID (Client-ID) → dies ist Ihre MICROSOFT_CLIENT_ID

   • Verzeichnis-ID (Mandanten-ID) → dies ist Ihre MICROSOFT_TENANT_ID (oder verwenden Sie die Zeichenfolge common für Multi-Mandanten- und persönliche Kontounterstützung)

7. API-Berechtigungen → Fügen Sie die folgenden delegierten Microsoft-Graph-Berechtigungen hinzu:

   • Mail.ReadWrite, Mail.Send

   • Calendars.ReadWrite

   • Contacts.ReadWrite

   • Tasks.ReadWrite

   • Files.Read.All (oder Files.ReadWrite.All, wenn Sie schreibfähige Datei-Tools möchten)

   • User.Read

   • offline_access (erforderlich für Aktualisierungstokens)

   • MailboxSettings.ReadWrite

   • Sites.Read.All

   • OnlineMeetings.Read

   • OnlineMeetingRecording.Read.All — Administratorzustimmung erforderlich

   • OnlineMeetingTranscript.Read.All — Administratorzustimmung erforderlich

   Nach dem Hinzufügen der beiden .Read.All-Berechtigungen klicken Sie auf der Seite „API-Berechtigungen" auf „Administratorzustimmung für [Mandantennamen] erteilen". Ohne Administratorzustimmung geben die Besprechungsaufzeichnungs-/Transkript-Tools 403 zurück.

8. Zertifikate & Geheimnisse → Neues Client-Geheimnis → notieren Sie den Wert (in 1Password). Dies ist Ihr MICROSOFT_CLIENT_SECRET. Sie können ihn nur einmal sehen – kopieren Sie ihn sofort.

4. wrangler.jsonc aktualisieren

Bearbeiten Sie wrangler.jsonc und ersetzen Sie beide:

• vars.MICROSOFT_CLIENT_ID – mit der Anwendungs-ID aus Schritt 3.6

• vars.MICROSOFT_TENANT_ID – mit der Verzeichnis-ID aus Schritt 3.6 (oder common)

5. Geheimnisse festlegen

Generieren Sie einen neuen Genehmigungscode:

openssl rand -base64 32

Speichern Sie ihn in einem Passwortmanager und übertragen Sie ihn dann an Cloudflare:

wrangler secret put MCP_APPROVAL_CODE          # paste the value from above
wrangler secret put MICROSOFT_CLIENT_SECRET    # from Step 3.8

6. Erste Bereitstellung (um die Worker-URL zu erfahren)

npm run deploy

Wrangler gibt Ihre Worker-URL aus – etwa https://outlook-mcp.<your-account>.workers.dev. Speichern Sie sie.

7. WORKER_URL und die Microsoft-Redirect-URI aktualisieren

Zwei Aktualisierungen sind erforderlich:

a) Bearbeiten Sie wrangler.jsonc – ersetzen Sie unter vars die WORKER_URL durch die URL aus Schritt 6.

b) In der Azure-AD-App (entra.microsoft.com → Ihre App → Authentifizierung → Plattform hinzufügen → Web) setzen Sie die Redirect-URI auf <your-worker-url>/oauth/callback. Ohne diese lehnt Microsoft den OAuth-Ablauf ab.

Stellen Sie dann erneut bereit:

npm run deploy

8. Microsoft verbinden (einmalig)

Besuchen Sie in Ihrem Browser <your-worker-url>/oauth/start. Fügen Sie Ihren MCP_APPROVAL_CODE ein. Sie werden zu Microsoft weitergeleitet, um sich anzumelden und die Berechtigungen aus Schritt 3.7 zu erteilen. Nach der Zustimmung landen Ihre verschlüsselten Upstream-Tokens in OAUTH_KV. Die Aktualisierung erfolgt danach automatisch.

Sie können die Verbindung bestätigen, indem Sie <your-worker-url>/oauth/status besuchen – dort sollte connected: true stehen.

9. Claude.ai verbinden

1. Gehen Sie in Claude.ai zu Einstellungen → Integrationen → MCP-Server hinzufügen

2. Server-URL: <your-worker-url>/mcp

3. Claude.ai leitet Sie zur /authorize-Seite Ihres Workers weiter

4. Fügen Sie Ihren MCP_APPROVAL_CODE ein und bestätigen Sie

5. Sie sind verbunden – Claude hat jetzt die 38 Outlook- und Teams-Tools zur Verfügung

E-Mail-Signatur

Optional. Wenn konfiguriert, hängt der Worker Ihre Signatur beim Senden an, sodass der aufrufende Agent sie nie reproduzieren muss – sie kann nicht umschrieben, gekürzt oder vergessen werden.

Übergeben Sie include_signature: true an eines der Tools send_email, schedule_send, reply_to_email, forward_email, create_draft, update_draft, create_reply_draft, create_reply_all_draft oder create_forward_draft. Der Standardwert ist false, sodass bestehende Aufrufer nicht betroffen sind.

Bei Entwürfen wird die Signatur zum Zeitpunkt der Entwurfserstellung eingefügt, nicht beim Senden – send_draft akzeptiert nur eine ID und berührt den Textkörper nie. Das bedeutet, dass der signierte Textkörper das ist, was Sie vor dem Senden überprüfen. Bei update_draft gilt das Flag nur, wenn Sie auch einen neuen body übergeben (sonst gibt es nichts zu signieren, und es würde den Entwurf durch einen nur aus Signatur bestehenden Textkörper ersetzen); dieser Fall wird in den notes der Antwort gemeldet, anstatt den Entwurf stillschweigend zu löschen.

Kalendereinladungen

create_calendar_event und update_calendar_event akzeptieren dasselbe include_signature-Flag und hängen die Signatur an die Beschreibung des Ereignisses an. Es verwendet denselben SIGNATURE_HTML-Block wie E-Mail – einschließlich der Marketing- Call-to-Action-Buttons –, sodass es eher für eine kundenorientierte Einladung geeignet ist als für eine interne Besprechung; deshalb ist es pro Ereignis optional. update_calendar_event folgt derselben Absicherung wie update_draft: Das Flag gilt nur, wenn Sie auch eine neue description übergeben.

Einrichtung

cp signature-block.example.html signature-block.html   # then edit it
wrangler secret put SIGNATURE_HTML < signature-block.html
wrangler secret put SIGNATURE_LOGO_URL                 # paste your HTTPS logo URL

signature-block.html ist absichtlich gitignored. Die Signatur ist Bereitstellungskonfiguration, kein Quellcode: Ein Fork, der eine eingecheckte Signatur geerbt hat, würde E-Mails mit dem Namen, der Telefonnummer und den Buchungslinks einer anderen Person senden. Nur der Platzhalter signature-block.example.html ist eingecheckt.

Das __LOGO_URL__-Token in SIGNATURE_HTML wird zur Laufzeit durch SIGNATURE_LOGO_URL ersetzt.

Das Logo muss über HTTPS öffentlich erreichbar sein. E-Mail-Clients laden es vom Empfängergerät – es hat keinen Zugriff auf Ihr Netzwerk, die Bindungen Ihres Workers oder auf Anmeldeinformationen, die Sie besitzen. Eine private, authentifizierte oder localhost-URL wird für alle als defektes Bild angezeigt. Wenn SIGNATURE_LOGO_URL nicht gesetzt ist, wird das <img> vollständig entfernt, anstatt ein defektes src auszugeben.

Wenn SIGNATURE_HTML nicht gesetzt ist, ist das Flag ein stiller No-op – die E-Mail wird ohne Signatur gesendet. Eine nicht konfigurierte Bereitstellung verursacht nie Fehler.

Verhalten

• Erzwingt HTML. Eine Signatur in einem Klartext-Textkörper wird als sichtbares rohes Markup gerendert, daher wird body_type auf html überschrieben, wenn das Flag gesetzt ist. Wenn Sie explizit body_type: "text" übergeben haben, wird die Überschreibung in den notes der Tool-Antwort gemeldet, nie stillschweigend angewendet.

• Klartext-Textkörper werden maskiert, dann werden Zeilenumbrüche zu <br>, sodass Ihre Zeilen- umbrüche den erzwungenen HTML-Wechsel überstehen und einzelne <-Zeichen nicht zu Markup werden können.

• Idempotent. Wenn der Textkörper die Signatur bereits enthält – erkannt durch den eigenen Marker des Workers oder durch den markanten Text der Signatur – wird sie nicht doppelt angehängt.

• Antworten und Weiterleitungen platzieren die Signatur über dem zitierten Original, nicht am Ende des gesamten Threads.

• Leerer Textkörper sendet nur die Signatur, ohne führende Leerzeilen.

Sicherheitshinweis

Die Signatur wird nach der Bereinigung des Aufrufer-Textkörpers angehängt. Dies ist beabsichtigt und tragend: sanitizeOutboundHtml entfernt jedes style=-Attribut (eine reine Attribut-XSS-Senke), und die Signatur besteht vollständig aus Inline-Stilen. Würde man sie durch den Bereiniger schicken, würden die Logogröße, der Trenner und die CTA-Buttons entfernt.

Die beiden Zeichenfolgen haben unterschiedliche Vertrauensstufen. Der Textkörper wird vom Agenten geliefert und ist nicht vertrauenswürdig, daher wird er weiterhin vollständig bereinigt. Die Signatur ist eine vom Betreiber gelieferte Bereitstellungskonfiguration, die über wrangler secret put gesetzt wird – jeder, der dieses Geheimnis setzen kann, kann den Worker bereits vollständig ändern. Siehe src/signature.ts.

Lokale Entwicklung

cp .dev.vars.example .dev.vars   # fill in MCP_APPROVAL_CODE + MICROSOFT_CLIENT_SECRET; .dev.vars is gitignored
npm test                          # 171 tests via vitest with workers pool
npm run typecheck                 # tsc --noEmit
npm run dev                       # wrangler dev — local at http://localhost:8787

Endpunkte

• GET /.well-known/oauth-authorization-server — OAuth-Metadaten (öffentlich)

• GET /.well-known/oauth-protected-resource — Ressourcen-Metadaten (öffentlich)

• GET /authorize — Seite zum Einfügen des Genehmigungscodes (öffentlich)

• POST /approve — Übermittlung des Genehmigungscodes (ratenbegrenzt)

• POST /token — OAuth-Token-Austausch (ratenbegrenzt)

• POST /register — Dynamische Client-Registrierung gemäß RFC 7591 (ratenbegrenzt)

• GET /oauth/start — Microsoft-OAuth-Flow starten (durch MCP_APPROVAL_CODE geschützt)

• GET /oauth/callback — Microsoft-OAuth-Umleitungsziel

• GET /oauth/status — Verbindungsstatus prüfen (durch MCP_APPROVAL_CODE geschützt)

• POST /mcp — JSON-RPC-Tool-Dispatch (durch Bearer-Token geschützt, ratenbegrenzt)

Stack

• Cloudflare Workers (compatibility_date 2025-04-28, nodejs_compat)

• TypeScript (strict)

• Hono v4

• Zod v4

• Vitest mit @cloudflare/vitest-pool-workers (171 Tests)

• @bashco/mcp-toolkit — gemeinsame Infrastruktur für OAuth, Krypto, Ratenbegrenzung und Dispatch

Highlights der Sicherheitsarchitektur

• Zweistufiger HTML-Sanitiser mit Entitätsnormalisierung bei ausgehenden E-Mail-Vorschauen

• SSRF-Schutz mit 32-Bit-IP-Normalisierung bei ausgehendem HTTP

• Parsing der Microsoft-Graph-odata-Fehlerhüllen für strukturierte Fehlerrückgaben

• Domänenspezifische Tool-Dateien unter src/tools/ (mail, calendar, contacts, tasks, files, meetings, settings) für Auditierbarkeit

Kontinuierliche Bereitstellung

.github/workflows/deploy.yml führt bei jedem Push auf main vitest run aus und stellt anschließend auf Cloudflare bereit. Um dies in Ihrem Fork zu aktivieren, legen Sie zwei Repository-Secrets fest:

• CLOUDFLARE_API_TOKEN — erstellen Sie unter dash.cloudflare.com/profile/api-tokens (verwenden Sie die Vorlage „Edit Cloudflare Workers")

• CLOUDFLARE_ACCOUNT_ID — finden Sie unten rechts in Ihrem Cloudflare-Dashboard

Mitwirken

Issues und PRs sind willkommen unter github.com/doublebash/outlook-mcp.

Für Änderungen am zugrunde liegenden OAuth-/Krypto-/Ratenbegrenzungs-Code: Das Toolkit befindet sich unter github.com/doublebash/mcp-toolkit — reichen Sie Issues dort ein.

Sicherheit

Eine Schwachstelle gefunden? Bitte kein öffentliches Issue eröffnen. Eröffnen Sie stattdessen eine private Security Advisory auf GitHub.

Lizenz

MIT — Copyright (c) 2026 Bashar Basheer.