Enterprise Support MCP Server

Ein leichtgewichtiger Enterprise-KI-Integrationsprototyp, der demonstriert, wie Geschäftsfunktionen über das Model Context Protocol (MCP) für Large Language Models verfügbar gemacht werden können.

Das Projekt stellt Kunden- und Bestellinformationen über einen Python-basierten MCP-Server bereit. Ein Mistral-betriebener KI-Assistent entdeckt dynamisch die verfügbaren MCP-Tools und entscheidet anhand von natürlichsprachlichen Supportanfragen, welche Tools aufgerufen werden sollen.

Bei komplexeren Anfragen kann der Assistent iterativ mehrere Tool-Aufrufe ausführen, bis genügend Informationen für eine abschließende Antwort vorliegen.

Alle in diesem Projekt verwendeten Kunden- und Bestelldatensätze sind synthetische Demodaten.

Hauptfunktionen

• Model Context Protocol (MCP) Server und Client

• Dynamische MCP-Tool-Erkennung

• LLM-gesteuerte Tool-Auswahl mit Mistral AI

• Mehrschrittiger Tool-Aufruf-Workflow

• Natürlichsprachliche Interaktion mit Unternehmensdaten

• Kunden- und Bestellabfrage

• Pydantic-Datenmodelle

• SQLite-Persistenz

• Strukturierte Fehlerbehandlung

• Trennung von MCP-, Persistenz- und KI-Integrationsschichten

Related MCP server: E-commerce MCP Server

Architektur

flowchart TD
    U[User] --> L[Mistral LLM]
    L --> C[MCP Client]
    C --> S[Enterprise Support MCP Server]
    S --> D[(SQLite Customer / Order Database)]
    D --> S
    S --> C
    C --> L
    L --> U

Das LLM greift nicht direkt auf die Datenbank zu.

Stattdessen werden Unternehmensfunktionen über standardisierte MCP-Tools bereitgestellt. Der MCP-Client entdeckt diese Tools dynamisch und stellt ihre Schemata dem LLM zur Verfügung.

Das LLM entscheidet dann, welches Tool für eine bestimmte Benutzeranfrage erforderlich ist.

Beispiel-Workflow

Ein Benutzer gibt ein:

Show me customer 1001.

Die Anwendung führt den folgenden Workflow aus:

User request
    ↓
Mistral LLM
    ↓
Selects get_customer
    ↓
MCP Client
    ↓
Enterprise Support MCP Server
    ↓
SQLite
    ↓
Customer data
    ↓
MCP Client
    ↓
Mistral LLM
    ↓
Natural-language response

Beispielergebnis:

Here is the information for customer 1001:

- Name: Anna Schmidt
- Email: anna@example.com
- Status: ACTIVE

Der Anwendungscode kodiert die Auswahl von get_customer nicht fest.
Das LLM wählt das passende MCP-Tool basierend auf der natürlichsprachlichen Anfrage des Benutzers aus.

Verfügbare MCP-Tools

get_customer

Ruft Kundeninformationen anhand der Kunden-ID ab.

Beispieleingabe:

{
  "customer_id": 1001
}

get_customer_orders

Ruft alle Bestellungen eines Kunden ab.

Beispieleingabe:

{
  "customer_id": 1001
}

get_order_status

Ruft den aktuellen Status und die Tracking-Informationen für eine Bestellung ab.

Beispieleingabe:

{
  "order_id": 5002
}

Technologie-Stack

• Python

• Model Context Protocol (MCP) Python SDK

• Mistral AI

• Pydantic

• SQLite

• asyncio

• python-dotenv

• uv

Erste Schritte

Voraussetzungen

Das Projekt erfordert:

• Python 3.11+

• pip

• uv

• einen Mistral-API-Schlüssel

Überprüfen Sie Ihre Python-Installation:

python --version

Überprüfen Sie uv:

uv --version

1. Repository klonen

git clone https://github.com/YOUR-USERNAME/enterprise-support-mcp-server.git
cd enterprise-support-mcp-server

Ersetzen Sie YOUR-USERNAME durch Ihren GitHub-Benutzernamen.

2. Virtuelle Umgebung erstellen

python -m venv .venv

Windows PowerShell

.venv\Scripts\Activate.ps1

Linux / macOS

source .venv/bin/activate

3. Abhängigkeiten installieren

pip install -r requirements.txt

Die Hauptabhängigkeiten umfassen:

mcp[cli]
mistralai
pydantic
python-dotenv

4. Mistral-API-Schlüssel konfigurieren

Erstellen Sie eine .env-Datei im Projektstammverzeichnis.

Sie können .env.example als Vorlage verwenden:

MISTRAL_API_KEY=your_mistral_api_key

Committen Sie niemals die eigentliche .env-Datei oder einen API-Schlüssel in Git.

5. Demodatenbank initialisieren

Führen Sie aus:

python init_db.py

Dies erstellt die lokale SQLite-Datenbank mit synthetischen Kunden- und Bestelldatensätzen, die von den MCP-Tools verwendet werden.

Testen

Das Projekt kann auf mehreren Ebenen getestet werden.

Test 1 – Datenbankzugriff

Die Datenbankfunktionen können unabhängig getestet werden, bevor MCP involviert ist.

Überprüfen Sie, ob die Demodatenbank initialisiert wurde:

python init_db.py

Die Datenbankschicht bietet Operationen für:

get_customer
get_customer_orders
get_order_status

Dies überprüft die Persistenzschicht unabhängig von MCP und dem LLM.

Test 2 – MCP-Server starten

Führen Sie aus:

python server.py

Bei einem stdio-basierten MCP-Server wird kein HTTP-Port oder Browser geöffnet.

Der Prozess wartet darauf, dass ein MCP-Client über die Standardeingabe/-ausgabe kommuniziert.

Stoppen Sie den Server mit:

Ctrl+C

Test 3 – MCP-Client ohne LLM

Führen Sie aus:

python client.py

Der Client verbindet sich mit dem MCP-Server und entdeckt die verfügbaren Tools.

Erwartete Tool-Erkennung:

Available tools:
- get_customer
- get_customer_orders
- get_order_status

Der Client kann dann die MCP-Tools direkt aufrufen.

Dieser Test überprüft:

MCP Client
    ↓
MCP protocol
    ↓
MCP Server
    ↓
SQLite
    ↓
MCP result

Für diesen Test ist kein Large Language Model erforderlich.

Test 4 – LLM-gesteuerte MCP-Tool-Auswahl

Führen Sie aus:

python llm_client.py

Die Anwendung sollte zuerst die vom Server entdeckten MCP-Tools anzeigen:

Available MCP tools:
- get_customer
- get_customer_orders
- get_order_status

Sie können dann eine natürlichsprachliche Anfrage eingeben.

Kundenabfrage

Show me customer 1001.

Erwartetes Verhalten:

Mistral
    ↓
get_customer
    ↓
customer_id = 1001

Die abschließende Antwort sollte die Informationen für Kunde 1001 enthalten.

Kundenbestellungen

Versuchen Sie:

Show me all orders for customer 1001.

Erwartetes Tool:

get_customer_orders

Bestellstatus

Versuchen Sie:

What is the status of order 5002?

Erwartetes Tool:

get_order_status

Anfrage ohne Unternehmensdaten

Versuchen Sie:

What can you help me with?

Das LLM sollte diese Anfrage beantworten können, ohne auf Kunden- oder Bestelldaten zuzugreifen.

Dies zeigt, dass die Tool-Ausführung dynamisch erfolgt und nicht für jede Anfrage ausgeführt wird.

Test 5 – Mehrschrittiger Tool-Aufruf

Der LLM-Client unterstützt iterative Tool-Ausführung.

Versuchen Sie eine komplexere Anfrage wie:

Customer 1001 says that one of her orders has not arrived.
Can you investigate?

Bei komplexen Anfragen kann der Assistent mehrere MCP-Tools verwenden, bevor die abschließende Antwort generiert wird.

Konzeptionell:

User
    ↓
Mistral
    ↓
MCP Tool
    ↓
Tool Result
    ↓
Mistral
    ↓
Another tool required?
    ├── Yes → MCP Tool → Result → Mistral
    └── No  → Final Response

Die Tool-Aufrufschleife hat eine maximale Anzahl von Iterationen, um eine versehentliche Endlosausführung zu verhindern.

Fehlerbehandlungstests

Der MCP-Server behandelt auch unbekannte Geschäftseinheiten.

Zum Beispiel:

Show me customer 9999.

Das entsprechende MCP-Tool gibt ein Fehlerergebnis zurück, anstatt Kundeninformationen zu erfinden.

Dies ist besonders wichtig für KI-basierte Unternehmensintegrationen: Tatsächliche Kunden- und Bestellinformationen müssen aus dem angeschlossenen Unternehmenssystem stammen und nicht vom LLM.

Projektstruktur

enterprise-support-mcp-server/
│
├── server.py
│   └── MCP server and tool definitions
│
├── client.py
│   └── MCP client for direct tool testing
│
├── llm_client.py
│   └── Mistral integration and agentic tool-calling workflow
│
├── database.py
│   └── Database access layer
│
├── models.py
│   └── Pydantic domain models
│
├── init_db.py
│   └── Creates synthetic demo data
│
├── requirements.txt
├── .env.example
├── .gitignore
└── README.md

Warum MCP?

Ein LLM kann auch anwendungsspezifische Funktionen direkt aufrufen.

MCP führt eine standardisierte Schnittstelle zwischen KI-Anwendungen und externen Fähigkeiten ein.

In diesem Projekt:

Mistral
   ↓
Tool Calling
   ↓
MCP Client
   ↓
Standardized MCP interface
   ↓
Enterprise Support MCP Server
   ↓
Enterprise capabilities

Das LLM ist dafür verantwortlich, zu entscheiden, welche Fähigkeit erforderlich ist.

MCP ist dafür verantwortlich, diese Fähigkeiten über ein standardisiertes Protokoll bereitzustellen.

Diese Trennung bedeutet, dass das Unternehmens-Backend nicht speziell für einen bestimmten LLM-Anbieter entwickelt werden muss.

Projektzweck

Das Projekt ist bewusst klein gehalten und konzentriert sich auf eine architektonische Frage:

Wie können bestehende Unternehmensfähigkeiten über eine standardisierte Integrationsschicht für KI-Assistenten verfügbar gemacht werden?

Es demonstriert die Kombination von:

• Unternehmenssystemintegration

• Model Context Protocol

• LLM-Tool-Aufruf

• Agentische Workflows

• Strukturierte Geschäftsdaten

• Trennung der Zuständigkeiten

Das Projekt dient als praktischer Prototyp für die Integration von KI-Assistenten in bestehende Unternehmensanwendungen.

Sicherheitshinweis

Dieses Repository enthält ausschließlich synthetische Demodaten.

Geben Sie keine API-Schlüssel, Anmeldeinformationen, Kundendaten oder andere sensible Informationen über Quellcode oder committete .env-Dateien preis.