MCP Customer Support AI

Ein produktionsorientiertes Model Context Protocol (MCP)-Projekt, entwickelt mit Node.js, TypeScript, MongoDB und einem LLM.

Dieses Projekt zeigt, wie eine KI-Anwendung über MCP-Tools strukturiert, sicher und skalierbar mit externen Systemen interagieren kann.

Das Projekt wird schrittweise entwickelt, von einem grundlegenden MCP-Server und Tool bis hin zu einem produktionsorientierten, KI-gestützten Kundensupportsystem.

🚀 Projektübersicht

Das Ziel dieses Projekts ist es, einen KI-gestützten Kundensupport-Assistenten zu entwickeln, der Benutzeranfragen versteht und MCP-Tools nutzt, um reale Vorgänge auszuführen.

Beispiel

Ein Benutzer kann fragen:

„Prüfe meine letzte Bestellung und erstelle ein Support-Ticket, wenn sie verspätet ist.“

Die KI kann ermitteln, dass sie Folgendes tun muss:

1. Den Kunden finden.

2. Die Bestellungen des Kunden abrufen.

3. Die verspätete Bestellung identifizieren.

4. Ein Support-Ticket erstellen.

Die KI greift nicht direkt auf die Datenbank zu.

Stattdessen interagiert sie über MCP-Tools mit der Anwendung.

                         User
                           │
                           ▼
                      AI / LLM
                           │
                           ▼
                      MCP Client
                           │
                           ▼
                    ┌─────────────┐
                    │ MCP Server  │
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
       Customer Tool   Order Tool   Ticket Tool
              │            │            │
              └────────────┼────────────┘
                           ▼
                       Services
                           │
                           ▼
                        MongoDB

🎯 Projektziele

Dieses Projekt demonstriert:

• MCP-Server-Entwicklung

• Erstellung von MCP-Tools

• MCP-Client-Kommunikation

• KI-Tool-Aufrufe

• TypeScript-Architektur

• MongoDB-Integration

• Service-Layer-Architektur

• Eingabevalidierung

• Fehlerbehandlung

• Authentifizierung und Autorisierung

• Logging und Monitoring

• Audit-Logging

• Produktionsorientierte MCP-Architektur

• KI-Agenten-Workflows

🛠️ Tech-Stack

Backend

• Node.js

• TypeScript

• MCP SDK

• Zod

• MongoDB

• Mongoose

KI

• LLM-Integration

• Tool-Aufrufe

• KI-Agent-Workflow

Entwicklung

• MCP Inspector

• Git

• GitHub

• npm

Geplante Produktionsinfrastruktur

• Docker

• Redis

• Authentifizierung

• Rate Limiting

• Logging

• Monitoring

• CI/CD

📁 Projektstruktur

mcp-customer-support/
│
├── src/
│   │
│   ├── index.ts
│   │
│   ├── tools/
│   │   ├── customer.tools.ts
│   │   ├── order.tools.ts
│   │   └── ticket.tools.ts
│   │
│   ├── services/
│   │   ├── customer.service.ts
│   │   ├── order.service.ts
│   │   └── ticket.service.ts
│   │
│   ├── models/
│   │   ├── customer.model.ts
│   │   ├── order.model.ts
│   │   └── ticket.model.ts
│   │
│   ├── db/
│   │   └── database.ts
│   │
│   ├── middleware/
│   │   └── auth.ts
│   │
│   └── utils/
│       ├── logger.ts
│       └── errors.ts
│
├── tests/
│
├── .env.example
├── .gitignore
├── package.json
├── package-lock.json
├── tsconfig.json
└── README.md

🏗️ Entwicklungsphasen

Das Projekt ist bewusst in Phasen unterteilt, sodass jede Phase ein wichtiges MCP- oder Produktionskonzept einführt.

Phase 1 – Grundlagen des MCP-Servers

Ziel

Einen grundlegenden MCP-Server erstellen und das erste Tool bereitstellen.

Umgesetzt

• Node.js-Projekt

• TypeScript-Konfiguration

• MCP SDK

• MCP-Server

• STDIO-Transport

• Zod-Eingabevalidierung

• Erstes MCP-Tool

• MCP Inspector-Integration

Erstes Tool

find_customer

Eingabe:

{
  "email": "ashwani@example.com"
}

Ausgabe:

{
  "id": "customer_123",
  "name": "Ashwani Yadav",
  "email": "ashwani@example.com"
}

Architektur

MCP Inspector
      │
      ▼
MCP Client
      │
      │ STDIO
      ▼
MCP Server
      │
      ▼
find_customer()
      │
      ▼
Dummy Data

Status

Abgeschlossen ✅

Phase 2 – Mehrere MCP-Tools

Ziel

Mehrere Tools erstellen, die reale Kundensupport-Abläufe abbilden.

Tools

find_customer
get_customer_orders
create_support_ticket

Beispiel

Beispiel

find_customer(email)

Bestellungen des Kunden abrufen

get_customer_orders(customerId)

Support-Ticket erstellen

create_support_ticket(
    customerId,
    orderId,
    issue
)

Erwartete Architektur

                    MCP Server
                        │
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
find_customer()   get_orders()   create_ticket()

Status

Geplant 🚧

Phase 3 – MongoDB-Integration

Ziel

Beispieldaten durch echte, persistente Daten ersetzen.

Datenbank

MongoDB

Collections

customers
orders
support_tickets

Architektur

MCP Tool
   │
   ▼
Service Layer
   │
   ▼
Mongoose
   │
   ▼
MongoDB

Beispiel

find_customer()
      │
      ▼
customer.service.ts
      │
      ▼
Customer Model
      │
      ▼
MongoDB

Vorteile

• Persistente Daten

• Saubere Datenbankabfragen

• Indizierung

• Schema-Validierung

• Skalierbarer Datenzugriff

Geplanter Index

customers.email

Damit bleibt die Suche nach Kunden per E-Mail auch bei wachsendem Datenbestand effizient.

Status

Geplant 🚧

Phase 4 – Service-Layer & Clean Architecture

Ziel

MCP-Tools getrennt von der Geschäftslogik halten.

Statt die Datenbanklogik direkt in das MCP-Tool zu schreiben:

Tool
 ↓
Service
 ↓
Database

Beispiel

customer.tools.ts
        │
        ▼
customer.service.ts
        │
        ▼
customer.model.ts
        │
        ▼
MongoDB

Warum?

Das bringt uns:

• Trennung von Verantwortlichkeiten

• Testbarkeit

• Wiederverwendbarkeit

• Wartbarkeit

• Einfachere Migration zu REST/GraphQL/internen Services

Status

Geplant 🚧

Phase 5 – MCP-Client

Ziel

Einen dedizierten MCP-Client entwickeln, der sich mit dem MCP-Server verbindet.

┌──────────────┐
│ MCP Client   │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ MCP Server   │
└──────────────┘

Der Client wird dazu in der Lage sein:

Tools entdecken

listTools()

Tools ausführen

callTool()

Zum Beispiel:

callTool(
    "find_customer",
    {
        email: "ashwani@example.com"
    }
)

Status

Geplant 🚧

Phase 6 – LLM-Integration

Ziel

Ein LLM mit dem MCP-Client verbinden.

Die Architektur sieht dann wie folgt aus:

User
 │
 ▼
LLM
 │
 ▼
MCP Client
 │
 ▼
MCP Server
 │
 ▼
Tools
 │
 ▼
MongoDB

Das LLM entscheidet auf der Grundlage der Benutzeranfrage, welches Tool aufgerufen werden soll.

Beispiel

Benutzer:

Check my latest order.

KI:

I need the customer's orders.

Tool:

get_customer_orders()

Das Tool returns die Bestelldaten.

Die KI erstellt daraufhin eine Antwort in natürlicher Sprache.

Status

Geplant 🚧

Phase 7 – KI-Agenten-Workflow

Ziel

Dem LLM die Durchführung mehrstufiger Workflows ermöglichen.

Beispielanfrage:

Check my latest order and create a support
ticket if it is delayed.

Der KI-Workflow:

             User Request
                   │
                   ▼
                 LLM
                   │
                   ▼
           find_customer()
                   │
                   ▼
        get_customer_orders()
                   │
                   ▼
           Analyze orders
                   │
                   ▼
        Is order delayed?
              /          \
            Yes           No
             │             │
             ▼             ▼
 create_support_ticket   Response
             │
             ▼
          Response

Das zeigt den Unterschied zwischen dem einfachen Bereitstellen von Tools und der Entwicklung eines KI-Agenten, der Tools orchestrsieren kann.

Status

Geplant 🚧

Phase 8 – Authentifizierung & Autorisierung

Ziel

MCP-Operationen absichern.

Die Authentifizierung prüft:

Wer ist der Benutzer?

Die Autorisierung prüft:

Was darf der Benutzer tun?

Beispielberechtigungen:

customer.read
order.read
ticket.create
ticket.update
admin.refund

Beispiel:

Customer
 ├── find_customer       ✅
 ├── get_orders          ✅
 ├── create_ticket       ✅
 └── refund_order        ❌

Admin
 ├── find_customer       ✅
 ├── get_orders          ✅
 ├── create_ticket       ✅
 └── refund_order        ✅

Status

Geplant 🚧

Phase 9 – Fehlerbehandlung

Ziel

Eine konsistente Fehlerbehandlung für alle Tools erstellen.

Beispiel:

CustomerNotFoundError
OrderNotFoundError
UnauthorizedError
ValidationError
DatabaseError
ToolExecutionError

Antworten der MCP-Tools werden Fehler klar ausweisen.

Beispiel:

{
  "isError": true,
  "message": "Customer not found"
}

Status

Geplant 🚧

Phase 10 – Logging & Beobachtbarkeit

Ziel

MCP-Operationen in der Produktion verfolgen.

Jede Tool-Ausführung sollte Informationen wie Voropred folgende Liefern:

Request ID
User ID
Tool name
Arguments
Execution time
Status
Error
Timestamp

Beispiel:

INFO Tool Execution

tool: get_customer_orders
customerId: customer_123
duration: 85ms
status: success

Monitoring-Ziele

• Tool-Latenz

• Fehlerrate

• Datenbank-Latenz

• KI-Antwort-Latenz

• Nutzungshäufigkeit der Tools

• Fehlgeschlagene Tool-Aufrufe

Status

Geplant 🚧

Phase 11 – Rate Limiting

Ziel

Den MCP-Server vor übermäßigen oder missbräuchlichen Anfragen schützen.

Mögliche Strategie:

User
 │
 ▼
Rate Limiter
 │
 ├── Allowed ──→ MCP Tool
 │
 └── Blocked ──→ Rate Limit Error

Für verteiltes Rate Limiting kann Redis eingeführt werden.

Beispiel:

100 requests / minute / user

Status

Geplant 🚧

Phase 12 – Audit-Logging

Ziel

Sensible KI-gesteuerte Vorgänge aufzeichnen.

Zum Beispiel:

User:
customer_123

AI requested:
create_support_ticket

Order:
order_123

Action:
Support ticket created

Timestamp:
2026-08-23T10:30:00Z

Dies ist besonders wichtig, wenn KI-Agenten Aktionen mitÄnderungen an Geschäftsdaten ausführen können.

Status

Geplant 🚧

Phase 13 – Testing

Unit-Tests

Test:

• Services

• Validierung

• Geschäftslogik

• Fehlerbehandlung

Integrationstests

Test:

MCP Tool
   ↓
Service
   ↓
MongoDB

MCP-Tests

Test:

MCP Client
   ↓
MCP Server
   ↓
Tool

Beispiel

find_customer
    ↓
valid email
    ↓
customer returned

und:

find_customer
    ↓
invalid email
    ↓
validation error

Status

Geplant 🚧

Phase 14 – Dockerisierung

Ziel

Die Anwendung containerisieren.

Docker
│
├── MCP Server
│
├── MongoDB
│
└── Redis

Beispiel-Prodarchitektur:

                 ┌─────────────┐
                 │   AI App    │
                 └──────┬──────┘
                        │
                        ▼
                 ┌─────────────┐
                 │ MCP Server  │
                 └──────┬──────┘
                        │
             ┌──────────┼──────────┐
             ▼          ▼          ▼
          MongoDB     Redis      Logs

Status

Geplant 🚧

Phase 15 – CI/CD

Ziel

Tests und Bereitstellung automatisieren.

Pipeline:

Developer
    │
    ▼
Git Push
    │
    ▼
GitHub Actions
    │
    ├── Install dependencies
    ├── Lint
    ├── Type check
    ├── Run tests
    ├── Build
    └── Deploy

Status

Geplant 🚧

🔐 Umgebungsvariablen

Commite .env niemals auf GitHub.

Verwende:

.env

für die lokale Entwicklung.

Beispiel:

MONGODB_URI=mongodb://localhost:27017/mcp-support
OPENAI_API_KEY=your_api_key
JWT_SECRET=your_secret

Stelle bereit:

.env.example

stattdessen:

MONGODB_URI=
OPENAI_API_KEY=
JWT_SECRET=

🧪 Entwicklung

Abhängigkeiten installieren:

npm install

Entwicklungsdemo Server starten:

npm run dev

Build ausführen:

npm run build

Production-Build ausführen:

npm start

🔍 MCP Inspector

Der MCP Inspector wird verwendet, um den MCP-Serveren zu testen und während der Entwicklung die verfügbaren Tools zu prüfen.

Beispiel:

npx @modelcontextprotocol/inspector npx tsx src/index.ts

Der Inspector ermöglicht uns:

• Eine Verbindung mit dem MCP-Server herzustellen

• Tools zu entdecken

• Tool-Schemas zu prüfen

• Tools auszuführen

• Antworten zu prüfen

• MCP-Kommunikation zu debuggen

🧠 Demonstrierte MCP-Konzepte

Dieses Projekt demonstriert die folgenden MCP-Konzepte:

MCP-Server

Stellt Funktionalitäten für MCP-Clients bereit.

MCP-Client

Stelle eine Verbindung zu MCP-Servern her und ruft deren Fähigkeiten auf.

Tools

Ausführbare Operationen, die KI-Systemen zur Verfügung gestellt werden.

Beispiele:

find_customer
get_customer_orders
create_support_ticket

Ressourcen

Schreibgeschützte Kontextdaten, die einem MCP-Client apresentiert werden können.

Mögliche zukünftige Ressourcen:

customer://customer_123
order://order_123

Prompts

Wiederverwendbare Prompt-Vorlagen/Workflows, die ück MCP bereitgestellt werden können.

Mögliches Beispiel:

customer_support_resolution

🏆 Produktionsarchitektur

Die endgültige Architektur soll wie nomzint aussehen:

                         ┌───────────────┐
                         │     User      │
                         └───────┬───────┘
                                 │
                                 ▼
                         ┌───────────────┐
                         │    LLM / AI   │
                         └───────┬───────┘
                                 │
                                 ▼
                         ┌───────────────┐
                         │  MCP Client   │
                         └───────┬───────┘
                                 │
                                 ▼
                    ┌────────────────────────┐
                    │       MCP Server       │
                    │                        │
                    │ Authentication         │
                    │ Authorization          │
                    │ Validation             │
                    │ Rate Limiting          │
                    │ Logging                │
                    └───────────┬────────────┘
                                │
               ┌────────────────┼────────────────┐
               ▼                ▼                ▼
        Customer Tool      Order Tool       Ticket Tool
               │                │                │
               └────────────────┼────────────────┘
                                ▼
                         Service Layer
                                │
                ┌───────────────┼───────────────┐
                ▼               ▼               ▼
             MongoDB          Redis          Logging

📌 Aktueller Fortschritt

💡 Beispiel für ein zukünftiges Gespräch

Sobald alle Phasen abgeschlossen sind, sollte das System Gespräche wie die folgenden unterstützen:

Benutzer

Meine letzte Bestellung ist noch nicht angekommen. Können Sie sie prüfen und ein Support-Ticket erstellen?

KI

1. Find customer
2. Retrieve orders
3. Identify delayed order
4. Create support ticket
5. Return ticket information

KI-Antwort

Ihre Bestellung ORD-123 ist verspätet. Ich habe das Support-Ticket TICKET-456 für Sie erstellt.

🎓 Abgedeckte Interviewthemen

Dieses Projekt kann verwendet werden, um Kenntnisse zu demonstrieren:

• Model Context Protocol

• KI-Agenten

• LLM-Tool-Aufrufe

• Function Calling

• MCP-Server

• MCP-Clients

• Tool-Discovery

• Tool-Ausführung

• TypeScript

• Node.js

• MongoDB

• Mongoose

• Clean Architecture

• Service-Layer-Architektur

• Authentifizierung

• Autorisierung

• RBAC

• Rate Limiting

• Redis

• Logging

• Observability

• Docker

• CI/CD

• GitHub Actions

• Testing

• Skalierbare Backend-Architektur

📈 Zukünftige Verbesserungen

Mögliche zukünftige Erweiterungen umfassen:

• Mehrere MCP-Server

• MCP-Zahlung

• E-Mail- MCP-Tools

• CRM-Integration

• Slack-Integration

• GitHub-Integration

• Vektordatenbank

• RAG und semantische Suche

• Human-in-the-Loop-Genehmigung

• Tool-Berechtigungsrichtlinien

• Tool-Execution-Tracing

• Verteiltes MCP-Peployment

• Kubernetes-Deployment

👨