MCP-Server – Sitzungsprotokolle

Unternehmen S.A. | Intern und vertraulich

MCP-Server, der auf Azure Functions Python aufbaut. Stellt MCP-Tools zur Verfügung, um den gesamten Ablauf der Protokollerfassung, Validierung, Entwurfserstellung, Bearbeitung, Genehmigung und abschließenden Konvertierung in Word zu verwalten.

Verfügbare Tools

Geschäftsablauf

ActaWizard → ValidateActa → GenerateDraft → Entwurf anzeigen → UpdateDraft (0 oder mehrfach) → ApproveDraft → GenerateDocx

Related MCP server: office-mcp-server

Voraussetzungen

• Python 3.10+ (empfohlen 3.12)

• Azure Functions Core Tools v4

• Azurite (Storage-Emulator – auch lokal erforderlich, da die MCP-Erweiterung ihn für den SSE-Transport verwendet)

• azure-functions>=1.24.0 (der mcp_tool_trigger funktioniert nicht mit älteren Versionen)

1. Abhängigkeiten installieren

python3 -m venv .venv
. .venv/bin/activate       # en Windows: .venv\Scripts\activate
pip install --upgrade pip
pip install -r requirements.txt

2. Tests ausführen (ohne Serverstart)

Die Tests in tests/test_tools.py rufen die Logik jedes Tools direkt auf, ohne die Azure Functions-Laufzeit oder Azurite. Sie sind der schnellste Weg, um zu überprüfen, ob die Geschäftslogik funktioniert:

pytest -v

Es sollten 5 Tests bestanden werden, die Folgendes abdecken: Sitzungserstellung, vollständiger Ablauf bis zur DOCX-Erstellung, Validierung mit fehlenden Feldern und dass ein genehmigter Entwurf nicht bearbeitet werden kann.

3. Den echten MCP-Server starten

# En otra terminal, arrancar el emulador de storage:
azurite --silent --location .azurite --debug .azurite/debug.log
# o, en VS Code: Ctrl+Shift+P -> "Azurite: Start"

func start

Der MCP-Server macht den Webhook verfügbar unter:

http://localhost:7071/runtime/webhooks/mcp

4. Tools End-to-End testen

Zwei Möglichkeiten:

a) MCP Inspector (empfohlen, spricht das echte Protokoll):

npx @modelcontextprotocol/inspector

Mit http://localhost:7071/runtime/webhooks/mcp/sse verbinden, Tools auflisten und einzeln aufrufen, dabei die JSON-Antwort anzeigen.

b) Postman: tests/Actas_MCP_Postman.json importieren und die Requests der Reihe nach ausführen (01 bis 07). Die ersten beiden Requests speichern automatisch session_id und draft_id als Sammlungsvariablen für die folgenden.

Wichtige Hinweise

• local.settings.json befindet sich in .gitignore. Laden Sie keine Anmeldeinformationen in das Repository hoch.

• Der Status (Sitzungen, Entwürfe) wird in .data/*.json neben dem Projekt gespeichert. Dies ist für die lokale Entwicklung ausreichend, aber nicht für die Produktion geeignet: In Azure Functions ist das lokale Dateisystem weder persistent noch wird es zwischen Instanzen geteilt. Vor dem Deployment mit mehr als einer Instanz ersetzen Sie tools/storage.py durch Azure Table Storage, Cosmos DB oder Blob Storage.

• In host.json ist system.webhookAuthorizationLevel: "Anonymous" eingestellt, um lokale Tests zu erleichtern. Vor dem Deployment nach Azure ändern Sie es auf "Function" oder "System", um den Schlüssel mcp_extension zu benötigen.

• UpdateDraft interpretiert Anweisungen auf Spanisch mit einfachen Regeln (ersetzen/löschen/hinzufügen); mehrdeutige Anweisungen werden am Ende des Entwurfs hinzugefügt, anstatt chirurgisch angewendet zu werden. Dies ist eine bekannte Einschränkung, kein Fehler.

Kurztipps

• ActaWizard gibt sessionId, status, nextField und question zurück.

• ValidateActa gibt complete und missingFields zurück.

• GenerateDraft erstellt den Entwurf mit draftId und draftMarkdown.

• UpdateDraft kann einen genehmigten Entwurf nicht bearbeiten.

• GenerateDocx funktioniert nur, wenn der Entwurf genehmigt ist, und gibt die Datei als fileBase64 zurück (dekodieren, um die .docx-Datei zu erhalten).