Siebel MCP Gateway

Stellt die Oracle Siebel REST API als MCP-Tools über streamable HTTP bereit, sodass ein agentischer Client Siebel-Datensätze abfragen/erstellen/aktualisieren/löschen und den Objektkatalog abrufen kann, ohne selbst Siebel-Anmeldeinformationen zu besitzen.

Der Mock-Modus modelliert ein synthetisches Demo-Schema für Gesundheitsüberweisungen (Patient → Gemeinschafts-/Krankenhausüberweisung → Form-17-Verpflichtung → Behandlungsverlauf), das dazu gebaut ist, eine Reihe dokumentierter, bewusster Datenqualitätsbefunde getreu zu tragen, anstatt sie zu glätten – doppelte Patientendatensätze über zwei Organisationen, ein Statusfeld, das tatsächlich Dringlichkeit enthält, ein Skript, das die angegebenen Grenzen eines Workflows stillschweigend überschreibt, zwei „visits remaining“-Felder, die auseinanderdriften. Alle Daten sind synthetisch.

Stack

Python 3.12+, das offizielle mcp SDK (MCPServer, der aktuelle Name für das, was in älteren SDK-Versionen FastMCP hieß), httpx für ausgehende Siebel-Aufrufe, uvicorn als ASGI-Server.

Related MCP server: MuleSoft Code MCP

Local run

python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
# Fill in .env, or for a first run without a live Siebel instance:
#   MOCK_MODE=true
#   MCP_GATEWAY_TOKEN=<any string you'll also give your client>
MOCK_MODE=true MCP_GATEWAY_TOKEN=dev-token \
  uvicorn app.server:app --host 0.0.0.0 --port 8000

Health-Check: curl http://localhost:8000/healthz → {"status":"ok"} (keine Authentifizierung erforderlich, damit Plattform-Health-Checker funktionieren).

MCP-Endpunkt: http://localhost:8000/mcp – jede Anfrage benötigt Authorization: Bearer <MCP_GATEWAY_TOKEN>, da der Endpunkt selbst keine andere Zugriffskontrolle hat, sobald er öffentlich bereitgestellt wird.

Tests

python3 -m pytest -v

Alle Tests laufen gegen den In-Memory-Mock-Store oder einen gemockten HTTP-Transport – keine Netzwerkaufrufe, keine Live-Siebel-Instanz erforderlich.

Deploying to Render

1. Pushen Sie dieses Repo auf GitHub.

2. Gewähren Sie Render zuerst Zugriff auf das Repo, falls es noch nicht verbunden ist. Die GitHub-App von Render sieht nur Repos, denen sie explizit Zugriff gewährt hat – ein brandneues Repo erscheint nicht einfach deshalb in Render's Repo-Auswahl, weil Sie es besitzen. Gehen Sie zu github.com/settings/installations → finden Sie Render → Configure → wechseln Sie entweder zu „All repositories“ oder fügen Sie dieses Repo zur erlaubten Liste hinzu → Speichern. Erst dann erscheint es wieder im Verbindungsbildschirm von Render.

3. Im Render-Dashboard: New → Blueprint (nicht „Web Service“ – dieses Repo hat eine render.yaml, und Blueprint ist das, was sie liest). Verbinden Sie das Repo, bestätigen Sie den Branch main und den Standardpfad render.yaml.

4. Render zeigt ein Formular für jede Umgebungsvariable, die in render.yaml mit sync: false markiert ist – füllen Sie diese vor dem Bereitstellen aus:

   • MCP_GATEWAY_TOKEN – generieren Sie einen, z.B. openssl rand -hex 32

   • MOCK_MODE – true, um sofort mit der Bereitstellung von Mock-Daten zu beginnen (empfohlen, solange die echte Siebel-Instanz noch nicht bereit ist), false, wenn Sie bereits echte Siebel-Anmeldeinformationen haben, die Sie unten eingeben möchten

   • SIEBEL_BASE_URL / SIEBEL_USERNAME / SIEBEL_PASSWORD – nur erforderlich, wenn MOCK_MODE=false; lassen Sie sie leer, wenn Sie im Mock-Modus starten

5. Klicken Sie auf Deploy Blueprint. Render weist https://<your-service>.onrender.com zu.

Um eine dieser Einstellungen später zu ändern (z.B. MOCK_MODE umschalten, sobald die echte Siebel-Instanz bereit ist): Öffnen Sie den Dienst (nicht den Blueprint) → Tab Environment → Wert bearbeiten → Save Changes, was ein erneutes Bereitstellen auslöst.

Pointing your MCP client at the deployed gateway

• URL: https://<your-service>.onrender.com/mcp

• Transport: streamable HTTP

• Auth: ein statisches Bearer-Token/API-Schlüssel, nicht OAuth – setzen Sie den Header auf Authorization: Bearer <MCP_GATEWAY_TOKEN> (derselbe Wert wie in Schritt 4 oben). Wenn die Auth-Oberfläche Ihres Clients einen Header-Namen und einen rohen Wert getrennt erwartet statt eines kombinierten Headers, ist der Header-Name Authorization und der Wert Bearer <token> (einschließlich des Wortes „Bearer“) – falls das zu einem 401 führt, versuchen Sie, nur das rohe Token anzugeben, da einige Clients das Präfix Bearer selbst hinzufügen.

Notes from actually deploying this

• Der Mock-Store ist nur im Speicher. Alles, was während einer Sitzung erstellt/aktualisiert/gelöscht wird, bleibt nur so lange bestehen, wie der Serverprozess läuft. Ein erneutes Bereitstellen oder das Herunterfahren der Free-Tier-Instanz von Render nach ~15 Minuten Leerlauf und der Kaltstart bei der nächsten Anfrage setzt es auf die ursprünglichen Seed-Daten zurück. Das ist erwartetes Mock-Modus-Verhalten, kein Fehler.

• Die clientseitige Transportabhängigkeit des mcp Python SDK ist httpx2, nicht einfaches httpx – nur relevant, wenn Sie Ihren eigenen MCP-Client gegen dieses Gateway schreiben und den streamable_http_client-Helfer des SDK verwenden, anstatt eine höherwertige Client-App; er erwartet ein httpx2.AsyncClient für das Argument http_client=, nicht ein reguläres httpx.AsyncClient.

Flip-to-live checklist

• Setzen Sie SIEBEL_BASE_URL auf die echte Instanz (ohne abschließenden Schrägstrich), z.B. https://<siebel-host>/siebel/v1.0

• Setzen Sie SIEBEL_USERNAME / SIEBEL_PASSWORD

• Setzen Sie SIEBEL_VERIFY_TLS=false nur, wenn die Instanz noch ein selbstsigniertes Zertifikat verwendet – stellen Sie es auf true zurück, sobald sie ein echtes hat

• Setzen Sie MOCK_MODE=false

• Stellen Sie erneut bereit und testen Sie dann mit siebel_list_objects und search_facilities, bevor Sie echten Agent-Traffic darauf richten

Tools

Generisch (funktionieren mit jeder Business Component: Contact, Employee, Medical Facility, Appointment Slot, Referral Request, Commitment Form, Treatment History):

Bequemlichkeits-Wrapper, schlankere Oberfläche für häufige Demo-Anfragen:

Notes on the Siebel REST API assumptions baked in here

• Auth ist HTTP Basic bei jedem ausgehenden Aufruf (getrennt von der eigenen Bearer-Token-Prüfung dieses Gateways bei eingehenden MCP-Anfragen – zwei verschiedene Auth-Ebenen, nicht verwechseln).

• Die URL-Grammatik ist {BASE}/data/{BusinessObject}/{BusinessComponent}. BO und BC sind hier nicht immer gleich benannt – z.B. ist Referral Request eine untergeordnete BC unter dem BO Patient Referral, Appointment Slot ist eine untergeordnete BC unter Appointment Management. Tools nehmen den BC-Namen; der Client sucht intern das richtige BO. Pfadsegmente sind URL-kodiert, sodass mehrteilige Namen funktionieren.

• Listenantworten kommen als {"items": [...]}; das "links"-Array jedes Datensatzes wird vor der Rückgabe an das Modell entfernt, um Tokens zu sparen.

• Nicht-2xx-Antworten werden als HTTP-Statuscode plus Siebels eigener Meldungstext angezeigt; eine 401 erhält ein klares Präfix „Siebel-Anmeldeinformationen prüfen“. Ausgehende Aufrufe haben ein Timeout von 30s.

• Mehrere Felder sind berechnet, nicht gespeichert (Age, Days Waiting, Visits Remaining, Is Expired, Entry Gap Days und die Facility/Doctor/Patient-Join-Felder) – sie werden bei jedem Lesen neu abgeleitet, entsprechend ihrem Verhalten als echte berechnete/Join-Felder der Business Component statt als physische Spalten.