Zum Hauptinhalt springen

❓ FAQ

🌐 F: Warum ist mein lokaler OpenAPI-Toolserver von der WebUI-Oberfläche aus nicht erreichbar?​

A: Wenn Ihr Toolserver lokal läuft (z. B. https://:8000), können browserbasierte Clients aufgrund von CORS (Cross-Origin Resource Sharing)-Richtlinien möglicherweise nicht darauf zugreifen.

Stellen Sie sicher, dass Sie CORS-Header in Ihrem OpenAPI-Server explizit aktivieren. Wenn Sie beispielsweise FastAPI verwenden, können Sie Folgendes hinzufügen

from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],  # or specify your client origin
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

Außerdem, wenn Open WebUI über HTTPS bereitgestellt wird (z. B. https://yourdomain.com), muss Ihr lokaler Server eine der folgenden Bedingungen erfüllen:

  • Zugriff von derselben Domäne über HTTPS (z. B. https://:8000).
  • ODER auf localhost (127.0.0.1) laufen, damit Browser die Sicherheit für die lokale Entwicklung lockern können.
  • Andernfalls können Browser unsichere Anfragen von HTTPS-Seiten an HTTP-APIs aufgrund von Mixed-Content-Regeln blockieren.

Um in der Produktion sicher über HTTPS zu arbeiten, müssen Ihre OpenAPI-Server ebenfalls über HTTPS bereitgestellt werden.

🚀 F: Muss ich FastAPI für meine Serverimplementierung verwenden?​

A: Nein! Obwohl unsere Referenzimplementierungen der Klarheit und Benutzerfreundlichkeit halber in FastAPI geschrieben sind, können Sie jedes Framework oder jede Sprache verwenden, die eine gültige OpenAPI (Swagger)-Spezifikation erzeugt. Einige gängige Optionen sind:

  • FastAPI (Python)
  • Flask + Flask-RESTX (Python)
  • Express + Swagger UI (JavaScript/Node)
  • Spring Boot (Java)
  • Go mit Swag oder Echo

Entscheidend ist, dass Ihr Server ein gültiges OpenAPI-Schema exponiert und über HTTP(S) kommuniziert. Es ist wichtig, für alle Endpunkte eine benutzerdefinierte operationId festzulegen.

🚀 F: Warum OpenAPI statt MCP?​

A: OpenAPI ist MCP in den meisten realen Szenarien aufgrund seiner Einfachheit, seines Tooling-Ökosystems, seiner Stabilität und seiner Entwicklerfreundlichkeit überlegen. Hier ist warum:

  • ✅ Bestehenden Code wiederverwenden: Wenn Sie bereits REST-APIs erstellt haben, sind Sie fast fertig – Sie müssen Ihre Logik nicht neu schreiben. Definieren Sie einfach eine konforme OpenAPI-Spezifikation und exponieren Sie Ihren aktuellen Code als Toolserver.

    Mit MCP mussten Sie Ihre Tool-Logik in einer benutzerdefinierten Protokollschicht neu implementieren, was zu doppelter Arbeit und einer größeren Angriffsfläche für die Wartung führte.

  • 💼 Weniger Wartung und Debugging: OpenAPI passt natürlich in moderne Entwicklungs-Workflows. Sie können Endpunkte mit Postman testen, Protokolle mit integrierten APIs einsehen, mit ausgereiften Ökosystem-Tools leicht Fehler beheben – und das oft, ohne Ihre Kernanwendung überhaupt zu ändern.

    MCP führte neue Schichten für Transport, Schema-Parsing und Laufzeit-Eigenheiten ein, die alle manuell debuggt werden mussten.

  • 🌍 Standardsbasiert: OpenAPI ist in der gesamten Tech-Branche weit verbreitet. Seine klar definierte Struktur bedeutet, dass Tools, Agenten und Server sofort interoperabel sind, ohne dass spezielle Brücken oder Übersetzungen erforderlich sind.

  • 🧰 Bessere Werkzeuge: Es gibt ein ganzes Universum von Werkzeugen, die OpenAPI unterstützen – automatische Client-/Server-Generierung, Dokumentation, Validierung, Mocking, Testen und sogar Security-Audit-Tools.

  • 🔐 Erstklassige Sicherheitsunterstützung: OpenAPI bietet native Unterstützung für Dinge wie OAuth2, JWTs, API-Schlüssel und HTTPS – was den Aufbau sicherer Endpunkte mit gängigen Bibliotheken und Standards erleichtert.

  • 🧠 Mehr Entwickler kennen es bereits: Die Verwendung von OpenAPI bedeutet, dass Sie eine Sprache sprechen, die Backend-Teams, Frontend-Entwickler, DevOps und Produktentwickler bereits vertraut ist. Es gibt keine Lernkurve oder kostspielige Einarbeitung.

  • 🔄 Zukunftssicher und erweiterbar: OpenAPI entwickelt sich mit API-Standards weiter und bleibt abwärtskompatibel. MCP hingegen war maßgeschneidert und experimentell – oft waren Änderungen erforderlich, wenn sich das umgebende Ökosystem änderte.

🧵 Fazit: OpenAPI ermöglicht es Ihnen, mehr mit weniger Aufwand, weniger Code-Duplizierung und weniger Überraschungen zu erreichen. Es ist ein produktionsreifer, entwicklerfreundlicher Weg, LLM-Tools zu betreiben – ohne alles von Grund auf neu zu bauen.

🔐 F: Wie sichere ich meinen OpenAPI-Toolserver?​

A: OpenAPI unterstützt branchenübliche Sicherheitsmechanismen wie:

  • OAuth 2.0
  • API-Schlüssel-Header
  • JWT (JSON Web Token)
  • Basic Auth

Verwenden Sie HTTPS in der Produktion, um Daten während der Übertragung zu verschlüsseln, und beschränken Sie Endpunkte mit angemessenen Auth/Authz-Methoden. Sie können diese direkt in Ihr OpenAPI-Schema über das Feld securitySchemes integrieren.

❓ F: Welche Art von Tools kann ich mit OpenAPI-Toolservern erstellen?​

A: Wenn es über eine REST-API bereitgestellt werden kann, können Sie es erstellen. Gängige Tooltypen sind:

  • Dateisystemoperationen (Dateien lesen/schreiben, Verzeichnisse auflisten)
  • Zugriff auf Git- und Dokumenten-Repositories
  • Abfragen von Datenbanken oder Erkundung von Schemata
  • Web-Scraper oder Zusammenfasser
  • Integrationen mit externen SaaS-Anbietern (z. B. Salesforce, Jira, Slack)
  • Speicher für LLM-gestützten Speicher / RAG-Komponenten
  • Sichere interne Microservices, die Ihrem Agenten zur Verfügung gestellt werden

🔌 F: Kann ich mehr als einen Toolserver gleichzeitig ausführen?​

A: Absolut. Jeder Toolserver läuft unabhängig und exponiert sein eigenes OpenAPI-Schema. Ihre Agentenkonfiguration kann auf mehrere Toolserver verweisen, sodass Sie je nach Bedarf mischen und anpassen können.

Es gibt keine Begrenzung – stellen Sie einfach sicher, dass jeder Server auf seinem eigenen Port oder seiner eigenen Adresse läuft und vom Host des Agenten aus erreichbar ist.

🧪 F: Wie teste ich einen Toolserver, bevor ich ihn mit einem LLM-Agenten verknüpfe?​

A: Sie können Ihre OpenAPI-Toolserver mit folgenden Tools testen:

  • Swagger UI oder ReDoc (standardmäßig in FastAPI integriert)
  • Postman oder Insomnia
  • curl oder httpie von der Kommandozeile
  • Das requests-Modul von Python
  • OpenAPI-Validatoren und Mock-Erzeuger

Nach der Validierung können Sie den Toolserver bei einem LLM-Agenten oder über Open WebUI registrieren.

🛠️ F: Kann ich die Referenzserver erweitern oder anpassen?​

A: Ja! Alle Server im Verzeichnis `servers/` sind als einfache Vorlagen konzipiert. Forken und modifizieren Sie sie, um:

  • Neue Endpunkte und Geschäftslogik hinzuzufügen
  • Authentifizierung zu integrieren
  • Antwortformate zu ändern
  • Verbindung zu neuen Diensten oder internen APIs herzustellen
  • Bereitstellung über Docker, Kubernetes oder jeden Cloud-Host

🌍 F: Kann ich OpenAPI-Toolserver auf Cloud-Plattformen wie AWS oder GCP ausführen?​

A: Ja. Diese Server sind reine HTTP-Dienste. Sie können sie als bereitstellen:

  • AWS Lambda mit API Gateway (serverless)
  • EC2- oder GCP Compute Engine-Instanzen
  • Kubernetes-Dienste in GKE/EKS/AKS
  • Cloud Run oder App Engine
  • Render, Railway, Heroku, etc.

Stellen Sie einfach sicher, dass sie sicher konfiguriert und öffentlich erreichbar sind (oder über VPN), falls sie vom Agenten oder Benutzer benötigt werden.

🧪 F: Was ist, wenn ich einen bestehenden MCP-Server habe?​

A: Tolle Neuigkeiten! Sie können unsere MCP-zu-OpenAPI-Bridge verwenden: mcpo. Das Bereitstellen Ihrer bestehenden MCP-basierten Tools als OpenAPI-kompatible APIs ist jetzt einfacher als je zuvor. Keine Umschreibungen, kein Kopfzerbrechen – einfach anschließen und loslegen! 🚀

Wenn Sie bereits Tools mit dem MCP-Protokoll erstellt haben, hilft Ihnen `mcpo` sofort, Kompatibilität mit Open WebUI und jedem OpenAPI-basierten Agenten zu erreichen – so bleiben Ihre harten Arbeit wertvollen Ergebnisse vollständig zugänglich und zukunftssicher.

Sehen Sie sich den Abschnitt zur optionalen Bridge zu MCP in der Dokumentation für Einrichtungsanweisungen an.

Schnellstart

uvx mcpo --port 8000 -- uvx mcp-server-time --local-timezone=America/New_York

✨ Das war's – Ihr MCP-Server ist jetzt OpenAPI-fähig!

🗂️ F: Kann ein OpenAPI-Server mehrere Tools implementieren?​

A: Ja. Ein einzelner OpenAPI-Server kann mehrere verwandte Funktionen unter verschiedenen Endpunkten anbieten. Zum Beispiel kann ein Dokumentenserver Suche, Upload, OCR und Zusammenfassung bereitstellen – alles innerhalb eines Schemas.

Sie können auch vollständig modularisieren, indem Sie pro Tool einen OpenAPI-Server erstellen, wenn Sie Isolation und Flexibilität bevorzugen.

🙋 Haben Sie weitere Fragen? Besuchen Sie die GitHub-Diskussionen, um Hilfe und Feedback von der Community zu erhalten
👉 Community-Diskussionen