Unterstützung für Remote MCP Server in unserer Infrastruktur hinzufügen

created: Montag, Juni 16, 2025

Down-to-Zero (DTZ) stand schon immer dafür, mehr mit weniger Watt und weniger Bytes zu erreichen. Von scale-to-zero Container-Scheduling bis zu solarbetriebenen Build-Runnern wird jeder Service, den wir ausliefern, an einer unerbittlichen Messlatte geprüft: Könnte das auch problemlos auf einer lüfterlosen Notebook-CPU in der Sonne laufen?

Heute freuen wir uns, den nächsten Schritt auf dieser Reise anzukündigen – Remote Model Context Protocol (MCP) Server, die Sie als leichte Docker-Container in jedem DTZ-Kontext starten können.


Warum MCP wichtig ist

MCP ist ein offener Standard, der es Sprachmodell-Hosts ermöglicht, für bestimmte Aufgaben spezialisierte „Server“ für Daten, Werkzeuge oder Aktionen anzusprechen – mittels eines einfachen, authentifizierten JSON-Streams. Man kann es sich vorstellen wie einen USB-C-Anschluss für KI-Agenten: ein Stecker, viele Peripheriegeräte. Durch das Betreiben eines MCP-Servers direkt neben Ihren Daten vermeiden Sie es, ganze Datensätze über einen LLM API-Aufruf zu schicken. Das passt perfekt zu unserem Mantra „Berechnung an den Rand verlagern, nicht ins Zentrum“.


Was sich geändert hat – Server-Sent Events im Balancer

Bislang beendet DTZs Multi-Tenant Load Balancer nur HTTP/1 und HTTP/2 Verbindungen. MCP hingegen nutzt Server-Sent Events (SSE) für seinen langlebigen, unidirektionalen Event-Stream. SSE funktioniert hervorragend über HTTP/2, aber Browser limitieren concurrent SSE-Verbindungen strikt, wenn sie auf HTTP/1 zurückfallen – meist sechs pro Ursprung.

Wir haben den Balancer daher um native SSE-Unterstützung erweitert:

Diese Verbesserung ermöglicht remote-first MCP Server: Sie können die Server-Komponente nun als Container-Image bereitstellen und jeder LLM-Client kann sicher über SSE ohne zusätzliche Proxies verbinden.


So stellen Sie es bereit

  1. Erstellen (oder laden Sie) ein MCP Server Image.

  2. Pushen Sie es in Ihre private DTZ Registry:

    docker push {context-id}.cr.dtz.dev/my-mcp-server:latest
    
  3. Erstellen Sie einen neuen Service in Ihrem Kontext und verweisen Sie auf das Image. Unser Scheduler zieht nur bei Bedarf und skaliert auf Null, wenn kein Host verbunden ist.

Da der Registry-Endpunkt innerhalb desselben energieeffizienten Meshs lebt, erfolgen Image-Pulls über das lokale Backbone, halten den ausgehenden Datenverkehr nahe Null und beschleunigen Kaltstarts.


Kleine Container, große Reichweite

Remote MCP Server benötigen typischerweise eine einzelne Rust- oder Go-basierte Binärdatei plus eine kleine Alpine-Basis. In unseren eigenen Tests verbraucht ein voll ausgestatteter GitHub-Integrationsserver 15 MiB RAM beim Start und unter 2 W im Leerlauf auf unseren DTZ Worker Nodes. Das lässt viel Spielraum für dutzende Server pro Node, bevor die Solarpanels überhaupt etwas merken.

Für Workloads, die doch Spitzen erzeugen, erlaubt DTZs cgroup-Isolation dem Kernel, Speicher sofort nach Abschluss des Jobs zurückzufordern. Zusammen mit dem SSE-Ruhezustand des Balancers kehrt Ihr Kontext nur Sekunden nach dem letzten Token-Stream zum Nullverbrauch zurück.


Ausblick

Wir integrieren aktiv den DTZ Identity Server via OAuth 2.1 in das MCP-Ökosystem, um sicherzustellen, dass jeder Stream nur an authentifizierte Clients ausgeliefert wird und Ihre Remote-Server minimal und sicher bleiben.


Weniger Energie, weniger Aufwand – einfach Kontext, wo Sie ihn brauchen.