MCP-Agent in Open WebUI: Tools und ReWOO

MCP-Agent in Open WebUI erstellen: Von einfachen Tools zu einem Planer

Ein Agent in Open WebUI für MCP beginnt einfach – wir geben dem LLM eine Reihe von Werkzeugen, um mit ClickHouse zu interagieren, und beobachten, was passiert. Anfangs stehen drei grundlegende Werkzeuge zur Verfügung: list_databases, list_tables und run_select_queries. Diese verarbeiten einfache SQL-Abfragen, doch je komplexer die Aufgaben werden, desto schwerer fällt es dem Modell, Datenstrukturen zu verstehen.

Lösung: Ein detaillierter Prompt mit konkreten Abfragebeispielen. Die Struktur enthält Variablen (portfolio_name, start_date, end_date), Anweisungen für LIKE-Filter und Muster wie Dt::date >= '{start_date}'. Zum Beispiel wird die Portfolio-Rendite mit Window-Funktionen berechnet:

WITH log_coef as (SELECT Portfolio, Dt,
    sum(log(TWR_dod+1)) OVER (
        PARTITION BY InvestmentPortfolioID
        ORDER BY Dt ASC ROWS BETWEEN UNBOUNDED PRECEDING AND 0 FOLLOWING
    ) AS TWR_cumulative_coef
FROM Contribution.contribution_twr_1s_mcp
WHERE lowerUTF8(Portfolio) LIKE '%{portfolio_name}%'
    AND Dt::date >= {start_date}
    AND Dt::date <= {end_date}
ORDER BY Dt DESC)
SELECT Portfolio, Dt, exp(TWR_cumulative_coef) - 1 AS TWR_cumulative
FROM log_coef;

Die Ergebnisse verbessern sich, bleiben aber instabil – Syntaxfehler und falsche Metriken treten weiterhin auf. RAG in Open WebUI hilft hier nicht weiter.

Erweiterung des Werkzeugkastens: Individuelle Tools ohne Halluzinationen

Ziel: Determinismus. Wir bauen vorgefertigte Werkzeuge mit Pydantic-Schemas. Das LLM wählt nur aus und parameterisiert sie; die Abfragen sind festgelegt. Zu den Tool-Klassen gehören:

• ClickHouseClientBase: Wrapper für zentrale MCP-Operationen.
• ProfitTool: Berechnet Renditen (TWR nach Datum, arithmetisch/geometrisch).
• PortfolioDiscoveryTool: Ermittelt Portfolio-Attribute (Liste, Typen, Strategien).
• PortfolioCashflowTool: Verfolgt Zu- und Abflüsse, analysiert Cashflows.

Beispiel-Schema für ClickHouseClientBaseParams:

class ClickHouseClientBaseParams(BaseModel):
    operation: Literal['list_databases', 'list_tables', 'run_select_query'] = Field(
        description='Art der Operation: list_databases, list_tables oder run_select_query'
    )
    database: Optional[str] = Field(default=None, description='Datenbankname')
    query: Optional[str] = Field(default=None, description='SQL-Abfrage')
    like: Optional[str] = Field(default=None, description='LIKE-Filter')
    not_like: Optional[str] = Field(default=None, description='NOT LIKE-Filter')


def clickhouse_client_base(params: ClickHouseClientBaseParams) -> str:
    # Logik für HTTP-Anfragen an http://clickhouse-mcp.services.kfim.int
    # Behandelt list_databases, list_tables, run_select_query
    # Ersetzt automatisch contribution_twr_1s_mcp durch vollständigen Tabellennamen

Die Funktion pydantic_to_openai_schema konvertiert diese Schemas in OpenAI-kompatible Formate – so entstehen keine Halluzinationen mehr. Die Werkzeuge liefern immer vorhersehbaren JSON-Output.

Vorteile dieser Methode:

• Determinismus: Gleiche Eingabe → gleiche Ausgabe.
• Skalierbarkeit: Neue Metriken als Werkzeuge hinzufügen.
• Debugging: Abfrage-Logik ist transparent, kein Black-Box-Verhalten des LLMs.

Die Grenzen der Einfachheit: Wenn Werkzeuge versagen

Ein naiver Agent scheitert bei komplexen Aufgaben: Mehrere Portfolios, Aggregationen, JOINs. Das Modell verwechselt Window-Funktionen und Datumsfilter. Selbst mit Beispielen erreichen Fehlerquoten 30–40 %. Für die Skalierung von Portfolio-Analysen müssen große Datensätze verarbeitet werden – Tausende TWR-Zeilen, Cashflow-Protokolle.

Verbesserung: Trennung in Planner und Executor

Zweite Iteration: Agent als ReWOO – Reason + Act. Der Planner (ein separates LLM) zerlegt Aufgaben in Schritte; der Executor ruft die Werkzeuge auf. Dies löst folgende Probleme:

• Datenfilterung: Volltextsuche über Portfolios mittels PortfolioDiscoveryTool.
• Sequenzsteuerung: Verkettete Abfragen (Liste → Filter → Aggregation).
• Kontextverwaltung: Tabellen werden zu einer zusammengeführt für die UI-Darstellung.

Der Planner generiert einen Plan:

• Schritt 1: Portfolios LIKE '%name%' auflisten.
• Schritt 2: TWR-Abfrage ausführen.
• Schritt 3: Aggregieren und anzeigen.

Der Executor folgt dem Plan strikt – keine Improvisation.

Volltextsuche in Aktion

Bei großen Tabellen ist Vorfilterung entscheidend. Das Werkzeug sucht mit lowerUTF8(Portfolio) LIKE '%query%' und liefert IDs/Typen. Dadurch beschleunigt sich run_select_query: statt vollständiger Durchläufe werden gezielte Abfragen ausgeführt.

Beispiel-Ablauf:

• PortfolioDiscoveryTool(like='stocks') → gibt ID-Liste zurück.
• ProfitTool(portfolios=ids, dates=range) → holt TWR-Daten.
• Zusammenführung in Pandas/DataFrame für die UI.

Wichtige Erkenntnisse

• Deterministische Werkzeuge basierend auf Pydantic reduzieren LLM-Fehler bei SQL.
• ReWOO-Ansatz trennt Planung und Ausführung für komplexe Workflows.
• Volltextsuche ist essenziell für das Filtern großer ClickHouse-Datensätze.
• Integration in Open WebUI ermöglicht sequenzielle Aufrufe mit finaler Tabellendarstellung.
• Chain-of-Thought-Prompts erhöhen die Stabilität, auch bei schwächeren Modellen.

— Editorial Team