🌊🔍 Lenses MCP-Server für Apache Kafka 🔎🌊

Dies ist der Lenses MCP-Server (Model Context Protocol) für Apache Kafka. Lenses bietet eine Entwickler-Experience-Lösung für Ingenieure, die Echtzeitanwendungen entwickeln, die mit Kafka verbunden sind. Es ist für Unternehmen konzipiert und wird durch ein leistungsstarkes IAM- und Governance-Modell unterstützt.

Mit Lenses können Sie Daten über eine Multi-Kafka- und Anbieter-Landschaft hinweg finden, erkunden, transformieren, integrieren und replizieren. Nun ist all diese Leistung über Ihren KI-Assistenten oder Agenten mittels dieses Lenses MCP-Servers für Kafka zugänglich.

Sehen Sie es erklärt und in Aktion, während Sie durch die Straßen von New York City spazieren!

Probieren Sie es noch heute mit der kostenlosen Lenses Community Edition aus (eingeschränkt durch die Anzahl der Benutzer und Enterprise-Funktionen). Lenses CE wird mit einem vorkonfigurierten Single-Broker-Kafka-Cluster geliefert, ideal für die lokale Entwicklung oder Demonstration. Verbinden Sie bis zu zwei Ihrer eigenen Kafka-Cluster und verwenden Sie dann natürliche Sprache, um mit Ihren Streaming-Daten zu interagieren.

Inhaltsverzeichnis

• 1. uv und Python installieren

• 2. Umgebungsvariablen konfigurieren

• 3. Lenses API-Schlüssel hinzufügen

• 4. Abhängigkeiten installieren und Server ausführen

• 5. Optionaler Context7 MCP-Server

• 6. Ausführung mit Docker

• 7. OAuth 2.1 Authentifizierung

1. uv und Python installieren

Wir verwenden uv für das Abhängigkeitsmanagement und die Projekteinrichtung. Wenn Sie uv nicht installiert haben, folgen Sie der offiziellen Installationsanleitung.

Dieses Projekt wurde mit Python 3.12 erstellt. Um sicherzustellen, dass Python korrekt installiert ist, führen Sie den folgenden Befehl aus, um die Version zu überprüfen.

uv run python --version

2. Umgebungsvariablen konfigurieren

Kopieren Sie die Beispiel-Umgebungsdatei.

cp .env.example .env

Öffnen Sie .env und tragen Sie die erforderlichen Werte ein, wie z. B. Ihre Lenses-Instanzdetails und den Lenses API-Schlüssel.

3. Lenses API-Schlüssel hinzufügen

Erstellen Sie einen Lenses API-Schlüssel, indem Sie ein IAM-Dienstkonto anlegen. Fügen Sie den API-Schlüssel mit dem Variablennamen LENSES_API_KEY zur .env-Datei hinzu.

4. Abhängigkeiten installieren und Server ausführen

Verwenden Sie uv, um eine virtuelle Umgebung zu erstellen, die Projektabhängigkeiten darin zu installieren und dann den MCP-Server mit der FastMCP-CLI unter Verwendung des Standard-stdio-Transports auszuführen.

uv sync
uv run src/lenses_mcp/server.py

Um den Server als Remote-Server auszuführen, verwenden Sie den http-Transport.

uv run fastmcp run src/lenses_mcp/server.py --transport=http --port=8000

Für die Ausführung in Claude Desktop, Gemini CLI, Cursor usw. verwenden Sie die folgende JSON-Konfiguration.

{
  "mcpServers": {
    "Lenses.io": {
      "command": "uv",
      "args": [
        "run",
        "--project", "<ABSOLUTE_PATH_TO_THIS_REPO>",
        "--with", "fastmcp",
        "fastmcp",
        "run",
        "<ABSOLUTE_PATH_TO_THIS_REPO>/src/lenses_mcp/server.py"
      ],
      "env": {
        "LENSES_API_KEY": "<YOUR_LENSES_API_KEY>"
      },
      "transport": "stdio"
    }
  }
}

Hinweis: Einige Clients erfordern möglicherweise den absoluten Pfad zu uv im Befehl.

5. Optionaler Context7 MCP-Server

Die Lenses-Dokumentation ist auf Context7 verfügbar. Es ist optional, aber sehr empfehlenswert, den Context7 MCP-Server zu verwenden und Ihre Prompts mit use context7 anzupassen, um sicherzustellen, dass die dem LLM zur Verfügung stehende Dokumentation auf dem neuesten Stand ist.

6. Ausführung mit Docker

Der Lenses MCP-Server ist als Docker-Image unter lensesio/mcp verfügbar. Sie können ihn je nach Anwendungsfall mit verschiedenen Transportmodi ausführen.

Schnellstart

Starten Sie den Server mit stdio-Transport (Standard):

docker run \
   -e LENSES_API_KEY=<YOUR_API_KEY> \
   -e LENSES_URL=http://localhost:9991 \
   lensesio/mcp

Starten Sie den Server mit HTTP-Transport (lauscht auf http://0.0.0.0:8000/mcp):

docker run -p 8000:8000 \
   -e LENSES_API_KEY=<YOUR_API_KEY> \
   -e LENSES_URL=http://localhost:9991 \
   -e TRANSPORT=http \
   lensesio/mcp

Starten Sie den Server mit SSE-Transport (lauscht auf http://0.0.0.0:8000/sse):

docker run -p 8000:8000 \
   -e LENSES_API_KEY=<YOUR_API_KEY> \
   -e LENSES_URL=http://localhost:9991 \
   -e TRANSPORT=sse \
   lensesio/mcp

Umgebungsvariablen

Veraltete Umgebungsvariablen (für Abwärtskompatibilität):

• LENSES_API_HTTP_URL, LENSES_API_HTTP_PORT

• LENSES_API_WEBSOCKET_URL, LENSES_API_WEBSOCKET_PORT

Diese werden automatisch von LENSES_URL abgeleitet, können aber explizit überschrieben werden.

Transport-Endpunkte

• stdio: Standard-Eingabe/Ausgabe (kein Netzwerk-Endpunkt)

• http: HTTP-Endpunkt unter /mcp

• sse: Server-Sent Events-Endpunkt unter /sse

Erstellen des Docker-Images

Um das Docker-Image lokal zu erstellen:

docker build -t lensesio/mcp .

7. OAuth 2.1 Authentifizierung

Wenn MCP_ADVERTISED_URL gesetzt ist, läuft der MCP-Server als OAuth 2.1 Protected Resource mit vollständiger RFC 7662 Token-Introspektion. Dies ersetzt den statischen LENSES_API_KEY-Ansatz durch Bearer-Token-Authentifizierung für HTTP-Transporte und setzt TRANSPORT standardmäßig auf http.

Funktionsweise

Der Authentifizierungsfluss umfasst drei Teilnehmer: den MCP-Client, den Autorisierungsserver (Lenses HQ unter LENSES_ADVERTISED_URL, standardmäßig LENSES_URL) und diesen MCP-Server (den Ressourcenserver).

MCP Client                    Auth Server                   MCP Server
    │                              │                             │
    │  1. GET /.well-known/        │                             │
    │     oauth-protected-resource │                             │
    │─────────────────────────────────────────────────────────►  │
    │  ◄── authorization_servers,                                │
    │      scopes_supported                                      │
    │                              │                             │
    │  2. POST /register (DCR)     │                             │
    │─────────────────────────────►│                             │
    │  ◄── client_id, secret       │                             │
    │                              │                             │
    │  3. /authorize + PKCE (S256) │                             │
    │─────────────────────────────►│                             │
    │  ◄── authorization_code      │                             │
    │                              │                             │
    │  4. POST /token              │                             │
    │─────────────────────────────►│                             │
    │  ◄── access_token            │                             │
    │                              │                             │
    │  5. MCP request + Bearer token                             │
    │─────────────────────────────────────────────────────────►  │
    │                              │  6. POST /oauth2/introspect │
    │                              │  ◄──────────────────────────│
    │                              │  ── active, scopes, exp ──► │
    │                              │                             │
    │  ◄── MCP response (or 401)                                 │
    │                              │                             │

Schritte 1–4 werden vom MCP-Client und dem Autorisierungsserver abgewickelt. Der MCP-Server ist nicht beteiligt.

Schritte 5–6 sind der Punkt, an dem dieser Server das Token validiert:

1. Protected Resource Metadata (RFC 9728) — RemoteAuthProvider stellt /.well-known/oauth-protected-resource/mcp bereit, damit Clients ermitteln können, welcher Autorisierungsserver zu verwenden ist und welche Scopes verfügbar sind.

2. Auto-Discovery — Bei der ersten eingehenden Anfrage ruft der DiscoveryTokenVerifier verzögert {LENSES_ADVERTISED_URL}/.well-known/oauth-authorization-server ab, um den introspection_endpoint zu ermitteln. Die Endpunkt-URL kann auch explizit über INTROSPECTION_URL festgelegt werden.

3. Token-Introspektion (RFC 7662) — Für jedes eingehende Bearer-Token sendet der Verifier einen POST-Request an den Introspektions-Endpunkt (/oauth2/introspect) ohne Client-Authentifizierung. Der Autorisierungsserver antwortet mit:

   • active — ob das Token gültig ist

   • scope — gewährte Scopes (z. B. read write)

   • client_id — der Besitzer des Tokens

   • exp — Ablaufzeitstempel

   Inaktive oder abgelaufene Token werden abgelehnt, bevor sie die Lenses API erreichen.

4. Token-Weiterleitung — Gültige Token werden via Authorization: Bearer <token> an die Lenses API weitergeleitet, damit Lenses seine eigenen Autorisierungsprüfungen durchführen kann.

Autorisierungs-Scopes

Der Server gibt drei Scopes in seinen Metadaten für geschützte Ressourcen an:

Scopes werden nicht global auf Introspektionsebene erzwungen — ein Token mit einer beliebigen Teilmenge dieser Scopes wird akzeptiert. Die Scope-Durchsetzung pro Tool kann mit dem require_scopes-Decorator von FastMCP hinzugefügt werden.

Konfiguration

In einer einfachen Bereitstellung sind nur zwei Umgebungsvariablen erforderlich:

LENSES_URL=https://lenses.example.com
MCP_ADVERTISED_URL=http://localhost:8000

TRANSPORT wird standardmäßig auf http gesetzt, sobald MCP_ADVERTISED_URL definiert ist, daher müssen Sie es nicht explizit setzen. LENSES_ADVERTISED_URL ist standardmäßig LENSES_URL, daher müssen Sie es nur in Split-Plane-Bereitstellungen setzen, bei denen der MCP-Server Lenses über eine interne Adresse erreicht, Clients ihn jedoch über eine öffentliche Adresse ansprechen:

# Split-plane: MCP server → Lenses over internal DNS,
# MCP clients → Lenses over the public URL
LENSES_URL=http://lenses-hq.internal:9991
LENSES_ADVERTISED_URL=https://lenses.example.com
MCP_ADVERTISED_URL=https://mcp.example.com

Lenses HQ (erreichbar über LENSES_ADVERTISED_URL) muss Folgendes unterstützen:

• OAuth 2.0 Authorization Server Metadata (RFC 8414) unter /.well-known/oauth-authorization-server

• Token-Introspektion (RFC 7662) am introspection_endpoint, mit deaktivierter Client-Authentifizierung

• PKCE mit S256 (RFC 7636) für Client-Autorisierungsflüsse

Der MCP-Server sendet bei der Introspektion eines Tokens keine Client-Anmeldeinformationen. Auf der Seite von Lenses HQ erfordert dies:

oauth2:
  authorizationServer:
    unauthenticatedIntrospection: true

in der Lenses HQ-Konfiguration. Ohne dieses Flag wird der Introspektions-Endpunkt den nicht authentifizierten POST des MCP-Servers ablehnen und jedes Bearer-Token wird als ungültig zurückgewiesen.

Ausführung mit OAuth

# Local development
LENSES_URL=https://lenses.example.com \
MCP_ADVERTISED_URL=http://localhost:8000 \
uv run src/lenses_mcp/server.py

# Docker
docker run -p 8000:8000 \
   -e LENSES_URL=https://lenses.example.com \
   -e MCP_ADVERTISED_URL=http://localhost:8000 \
   lensesio/mcp

Wenn MCP_ADVERTISED_URL nicht gesetzt ist, greift der Server zur Abwärtskompatibilität auf den statischen LENSES_API_KEY zurück und TRANSPORT wird standardmäßig auf stdio gesetzt.