HIBISCUS_MCP

HIBISCUS_MCP stellt ausgewählte Hibiscus-Funktionen als kleinen, Bearer-geschützten MCP-Server bereit. Der Server spricht intern per XML-RPC mit einem vorhandenen Hibiscus-Server und speichert selbst keine Bankdaten.

Container-Image: ghcr.io/safrano9999/hibiscus-mcp:latest

Zusammenspiel

MCP-Client
    │  Streamable HTTP + Bearer
    ▼
gepatchtes Supergateway :8000/mcp
    │  stdio
    ▼
HIBISCUS_MCP (server.mjs)
    │  HTTPS/XML-RPC
    ▼
Hibiscus-Server :8080/xmlrpc/

Das eigenständige Image benötigt deshalb immer einen erreichbaren Hibiscus-Server. Das Schwesterprojekt HIBISCUS-FEDORA44 integriert diesen MCP-Server und Hibiscus in einem gemeinsamen Fedora-Container.

Related MCP server: mcp-stdio-to-streamable-http-adapter

MCP-Tools

Ein erfolgreicher create_transfer-Aufruf bestätigt zunächst nur Speicherung und Sync-Anstoß. Die tatsächliche Bankausführung lässt sich anschließend über pending_transfers beziehungsweise den aktualisierten Kontostand prüfen.

Authentifizierung

Es gibt genau zwei gemeinsame Variablennamen:

Zwei Betriebsarten sind möglich:

1. Direktes Bearer-Passthrough: HIBISCUS_MCP_GATEWAY bleibt leer. Der vom MCP-Client gesendete Bearer wird als Hibiscus-Passwort verwendet.

2. Stealth-Gateway: HIBISCUS_MCP_GATEWAY ist gesetzt. Der Client muss diesen Bearer senden; nur der MCP-Prozess erhält zusätzlich HIBISCUS_STORE_PASSWORD für Hibiscus.

Der Gateway-Modus verhindert, dass ein MCP-Client das eigentliche Hibiscus-Passwort kennen muss. Wegen des Überweisungs-Tools sollte der MCP-Port nur in vertrauenswürdigen Netzen erreichbar sein.

Endpunkte

• MCP: http://HOST:8000/mcp

• Health: http://HOST:8000/healthz (ohne Authentifizierung)

• Transport: stateful Streamable HTTP

• Sitzungszeit: 60 Minuten

Der interne stdio-Server steht in server.mjs. Die HTTP-Brücke basiert auf einer fest gepinnten Supergateway-Revision mit den Patches unter patches/. Der Bearer wird beim MCP-Initialize an die Sitzung gebunden; Folgeanfragen derselben Sitzung müssen denselben Bearer senden. Für den internen, typischerweise selbstsignierten Hibiscus-Endpunkt ist die TLS-Zertifikatsprüfung bewusst deaktiviert.

Konfiguration und Deployment

Die Konfiguration wird durch config.sh aus den Vorlagen erzeugt:

./setup.sh

setup.sh erzeugt die Runtime-Dateien mit Modus 0600 und bereitet beide Varianten vor:

• Container: generiertes hibiscus-mcp.container als User-Quadlet verlinken.

• Bare Metal: generierte hibiscus-mcp.service als User-Service verlinken.

Es darf immer nur eine Variante aktiv sein. Für Bare Metal verwendet das Setup vorhandenes Node.js ab Version 20 oder installiert Node.js lokal und checksum-geprüft unter .runtime/. Supergateway wird ebenfalls lokal aus der fest gepinnten Revision gebaut.

Das Container-Deployment benötigt kein Volume und keine eigene Datenbank. Ein leerer HIBISCUS_MCP_PUBLISH_PORT veröffentlicht keinen Hostport; der Dienst kann dann ausschließlich über ein gemeinsames Podman-Netz erreicht werden.

Build

Das Containerfile baut zuerst das gepatchte Supergateway und den MCP-Server, prüft server.mjs und erzeugt anschließend ein minimales Alpine-basiertes Runtime-Image. Veröffentlichung und Smoke-Test erfolgen über container-image.yml.

Lizenz: MIT