Claude-Konnektoren lokal nachbauen: Warum ich das tue

Warum ich meine Claude-Konnektoren lokal nachbaue – MCP im eigenen Homelab

Lesezeit: ca. 13 Minuten

Ein Konnektor verbindet Claude mit einer App oder Datenquelle: Kalender, Notion, eine Datenbank. Anthropic bietet dafür fertige Konnektoren an, und für viele Anwendungsfälle sind die eine saubere Sache – einmal zusammenklicken, einmal autorisieren, fertig.

Der Haken beginnt dort, wo die Daten sensibel sind und das eigene Netzwerk nicht verlassen sollen. Genau da sitzt ein Homelab: Proxmox-Cluster, ein NAS voller Dokumente, Home Assistant mit jedem Bewegungsmelder im Haus, ein paar Datenbanken, die niemanden etwas angehen. Für dieses Szenario baue ich Konnektoren lieber selbst – als lokale MCP-Server auf eigener Hardware.

Technisch ist das kein Nischen-Bastelprojekt. Unter den Konnektoren steckt mit dem Model Context Protocol (MCP) ein offener Standard, den Anthropic veröffentlicht hat und der inzwischen von mehreren Werkzeugen unterstützt wird. Dieser Beitrag für aimageddon.de sortiert die Faktenlage August 2026: Was Konnektoren wirklich sind, warum die Unterscheidung zwischen remote und lokal über die ganze Entscheidung bestimmt, welche Hardware reicht, wie du deinen ersten Server aufsetzt – und wo die Fallstricke liegen.

Was Konnektoren wirklich sind

Konnektoren werden gern als „Brücken zwischen Claude und deinen Apps“ beschrieben. Das stimmt, verschweigt aber den entscheidenden Teil: Die Brücke ist standardisiert. Jeder Konnektor spricht dasselbe Protokoll — deshalb ist es dem Client egal, ob dahinter ein fremder Dienst oder dein eigener Python-Prozess auf dem NAS sitzt.

MCP – der offene Standard darunter

Das Model Context Protocol definiert, wie ein KI-Client mit einem Werkzeug-Server redet. Der Server bietet drei Dinge an: Tools (Funktionen, die aufgerufen werden können, etwa „lies Datei X“ oder „starte Container Y“), Resources (lesbare Datenquellen) und Prompts (vorgefertigte Abläufe). Der Client fragt beim Verbinden ab, was der Server kann, und ruft die Funktionen bei Bedarf auf.

Der Vorteil des offenen Standards: Du bist nicht auf einen Anbieter festgelegt. Dasselbe Protokoll wird inzwischen von weiteren Werkzeugen genutzt. Ein MCP-Server, den du heute baust, ist damit eine Investition, die auch bei einem Wechsel Bestand hat.

Der Punkt, an dem die meisten Homelab-Pläne scheitern

Hier liegt die wichtigste Unterscheidung, und sie wird oft falsch verstanden. Es gibt zwei Bauformen, und sie unterscheiden sich nicht nur in der Reichweite, sondern grundsätzlich darin, von wo aus die Verbindung aufgebaut wird.

Remote-Konnektoren: Fügst du einen Custom Connector hinzu, verbindet sich Claude von Anthropics Cloud-Infrastruktur aus zu deinem MCP-Server – und zwar bei jedem Client, also auch dann, wenn du Claude Desktop auf demselben Rechner nutzt. Daraus folgt zwingend: Dein Server muss über das öffentliche Internet erreichbar sein. Genau das ist für ein Homelab die entscheidende Hürde, und sie wird in vielen Anleitungen unterschlagen.

Desktop-Erweiterungen: Sie laufen als lokaler Prozess auf deiner Maschine, kommunizieren über stdio und erreichen lokale wie interne Ressourcen. Verfügbar sind sie nur in Claude Desktop und Claude Code – nicht im Web und nicht mobil.

Diese Einschränkung ist kein Bug, sondern der Preis der Datenhoheit. Ich fahre bewusst die lokale Variante: Was auf dem Handy funktionieren muss, läuft über offizielle Konnektoren. Was mein Netzwerk berührt, bleibt auf der Desktop-Erweiterung.

Der Trick, den größere Organisationen nutzen

Es gibt einen Mittelweg, der in der Dokumentation ausdrücklich als gängiges Muster genannt wird: Die Desktop-Erweiterung wird als sicherer Proxy zu internen MCP-Servern gebaut. Die Erweiterung läuft lokal beim Nutzer, spricht ins interne Netz und reicht nur weiter, was freigegeben ist. So bleibt die Sicherheitsarchitektur intakt, und trotzdem sind interne Systeme nutzbar.

Für ein Homelab mit mehreren Diensten ist das die elegantere Lösung, als jeden einzelnen Server öffentlich zu exponieren.

Ein Detail zum Packaging

Wer Desktop-Erweiterungen recherchiert, stößt auf zwei Dateiendungen. Seit September 2025 heißen die Pakete .mcpb (MCP Bundle) statt .dxt; bestehende .dxt-Erweiterungen funktionieren weiter, für Neues wird .mcpb empfohlen. Funktional hat sich nichts geändert, es ist reine Namenskonvention – aber ältere Anleitungen nennen noch die alte Endung.

Der Vorteil dieser Pakete: Ein-Klick-Installation ohne manuelle Konfigurationsdateien und ohne separat installiertes Node.js oder Python.

Meine Gründe: Datenhoheit und Kontrolle

Sensible Daten verlassen das Netzwerk nicht

Bei einem lokalen MCP-Server läuft die Werkzeug-Logik auf meiner Hardware – Filterung, Vorverarbeitung und Auswahl passieren dort. Nach außen geht nur, was ich im Tool-Design explizit herausgebe. Für Dokumente mit Personenbezug ist das der Unterschied zwischen „lässt sich DSGVO-konform argumentieren“ und „muss ich erst klären“.

Keine Abhängigkeit von Rate-Limits und Verfügbarkeit

Ein lokaler Server, der einen Container neu startet oder eine Log-Datei liest, hängt von keinem externen Dienst ab. Die einzige Cloud-Komponente bleibt das Modell selbst. Aber die Werkzeuge dahinter laufen, solange dein Homelab läuft.

Anpassbare Werkzeuge statt vorgefertigter Integrationen

Ein fertiger Konnektor gibt dir, was der Anbieter vorgesehen hat. Ein selbst gebauter Server gibt dir genau die Funktion, die du brauchst – mit deiner Fehlerbehandlung und deinen Sicherheitsgrenzen. Ich habe Werkzeuge, die drei Systeme in einem Aufruf kombinieren, weil es für meinen Arbeitsablauf sinnvoll ist. Kein Verzeichnis der Welt hätte diese Kombination im Angebot.

Die Hardware-Basis

Hier räume ich zuerst mit einem hartnäckigen Missverständnis auf: Ein MCP-Server führt keine KI-Inferenz aus. Er ist ein schlanker Prozess, der auf Funktionsaufrufe wartet, eine Datei liest, eine Datenbank abfragt, einen Container anstößt. Das Modell rechnet woanders. Für den reinen Konnektor-Betrieb brauchst du deshalb keine Grafikkarte.

Empfehlungen der Art „RTX 3090 oder besser“ beziehen sich auf das lokale Ausführen von Modellen – eine völlig andere Aufgabe. Wie sich das rechnet, steht in unserem Vergleich Mini-PC gegen Desktop-GPU.

Meine Wahl ist ein Proxmox-Node, auf dem ohnehin schon meine Dienste laufen. Der MCP-Server sitzt in einem eigenen LXC-Container – sauber getrennt, mit gezielt zugewiesenen Ressourcen und Netzwerkrechten.

RAM und CPU realistisch einschätzen

Ein einzelner Server im Leerlauf verbraucht wenig – ein paar Dutzend Megabyte RAM, kaum CPU. Interessant wird es bei parallelen Servern und bei der Arbeit, die ein Tool im Moment des Aufrufs leistet. Ein Werkzeug, das eine große Datenbank abfragt oder tausende Dateien durchsucht, zieht dann Last.

Grobe Orientierung: Für drei bis fünf leichte Server parallel plane ich lieber 4 GB RAM ein als 2, und lieber vier CPU-Kerne als zwei. Wichtig ist die Reserve für Lastspitzen, nicht der Dauerdurchschnitt.

Wer parallel dazu Modelle lokal betreiben will, spielt in einer anderen Liga — die Speicherplanung dafür steht in unserem Beitrag zu den fünf RAM-Fehlern bei lokalen KI-Modellen, die Kostenrechnung im Vergleich Homelab-KI-Server bauen oder kaufen.

Den ersten Server aufsetzen

SDK und Grundgerüst

Es gibt offizielle SDKs für Python und TypeScript. Nimm die Sprache, die dir liegt – die Konzepte sind identisch. Das Grundgerüst besteht aus drei Teilen:

• Server-Instanz anlegen – ein benanntes Objekt, das später deine Werkzeuge registriert.
• Tools definieren – jede Funktion bekommt einen Namen, eine Beschreibung und ein Schema für die Parameter. Die Beschreibung ist wichtiger, als sie aussieht: Sie ist die Bedienungsanleitung für das Modell und entscheidet, wann ein Werkzeug aufgerufen wird.
• Server starten – über den passenden Transport.

Ein erstes sinnvolles Tool ist ein reines Lese-Werkzeug – etwa „gib den Inhalt dieser Log-Datei zurück“. Damit testest du die ganze Kette, ohne dass ein Fehler etwas kaputtmachen kann.

Über stdio verbinden

Für lokale Server ist stdio der einfachste Transport: Der Client startet deinen Server als Kindprozess und kommuniziert über die Standard-Ein- und -Ausgabe. Du trägst den Server in die Konfiguration ein – Pfad zum Interpreter, Pfad zum Skript – und nach einem Neustart taucht das Werkzeug auf.

Kein offener Port, keine Netzwerkfreigabe, nichts, was von außen erreichbar wäre. Das ist die sicherste Variante und mein Standard für alles, was nur auf dem eigenen Rechner laufen muss.

In Claude Code lässt sich ein Server direkt über die Kommandozeile registrieren – für stdio-Server ebenso wie für HTTP-Endpunkte; die genaue Syntax steht in der Claude-Code-Dokumentation.

Wann HTTP nötig wird

Soll der Server auf einer anderen Maschine im Netz laufen – etwa auf dem NAS, während der Client auf dem Arbeitsrechner läuft –, brauchst du einen netzwerkfähigen Transport über HTTP. Ab hier reden wir über offene Ports, und damit wird das Sicherheitskapitel zur Pflicht.

Ein Hinweis, der viel Zeit spart: Über die API-Variante des MCP-Connectors lassen sich lokale stdio-Server nicht direkt anbinden – dort werden ausschließlich öffentlich erreichbare Server unterstützt, und der Funktionsumfang beschränkt sich auf Tool-Aufrufe. Wer Resources und Prompts braucht oder lokal bleiben will, arbeitet mit einem Client, der die Verbindung selbst hält.

Fang trotzdem mit stdio an: Erst wenn ein Werkzeug lokal sauber funktioniert, lohnt es sich, es über das Netz verfügbar zu machen.

Eigene Werkzeuge für den Alltag

Dateien, Datenbanken und Container

Das erste wirklich nützliche Tool war bei mir ein Datei-Werkzeug mit klar begrenztem Wurzelverzeichnis: lesen und suchen in einem festgelegten Projektordner, nirgends sonst. Dazu kamen mit der Zeit:

• Datenbank-Abfragen: ein Tool, das nur ausgewählte, lesende Queries zulässt – so wird eine bestehende Datenbank nutzbar, ohne dass irgendjemand SQL-Vollzugriff bekommt.
• Container-Steuerung: Werkzeuge, die den Status abfragen oder einen einzelnen Dienst kontrolliert neu starten – bewusst mit einer Whitelist, welche Container überhaupt angefasst werden dürfen.
• Log-Auswertung: ein Tool, das Logs filtert und zusammenfasst, statt rohe Gigabyte weiterzureichen. Die Vorfilterung passiert lokal.

Home Assistant und Proxmox

Die beiden Systeme, an denen sich der lokale Ansatz für mich am deutlichsten auszahlt. Beide haben APIs, beide enthalten Daten, die ich definitiv nicht in einer Cloud sehen will.

Ein Server, der die Home-Assistant-API kapselt, erlaubt Anfragen wie „welche Sensoren melden gerade einen ungewöhnlichen Wert“ – ausgewertet lokal, mit einer festen Grenze, welche Entitäten überhaupt sichtbar sind. Für Proxmox nutze ich ein reines Status- und Report-Werkzeug: Auslastung, laufende VMs, freier Speicher. Steuernde Eingriffe habe ich bewusst draußen gelassen; das Risiko-Nutzen-Verhältnis stimmt für mich dort nicht.

Häufige Fehler vermeiden

Sicherheit und Wartung

Ein selbst gebauter Konnektor gibt einem Sprachmodell die Erlaubnis, Funktionen auf deiner Hardware auszuführen. Das ist mächtig – und genau deshalb der Teil, den man nicht überspringen darf.

Vier Grundregeln

• Niemals ungesichert ins offene Netz. Ein netzwerkfähiger Server gehört hinter Authentifizierung – und im Idealfall gar nicht ins Internet, sondern nur ins eigene Netz, erreichbar über VPN.
• Least Privilege bei jedem Tool. Ein Lese-Tool bekommt nur Leserechte, ein Container-Tool nur die Container von der Whitelist.
• Isolierung des Hosts. Eigener Container oder eigene VM mit eingeschränktem Netzwerkzugriff. Wird der Prozess kompromittiert, ist der Schaden eingegrenzt.
• Eingaben validieren. Dein Server darf sich nicht darauf verlassen, dass ein Modell nie danebenliegt oder manipuliert wird.

Logging und Updates

Jeder meiner Server protokolliert, welches Tool wann mit welchen Parametern aufgerufen wurde. Das kostet fast nichts und zeigt nebenbei, ob die Werkzeuge so genutzt werden, wie gedacht. Dazu gehört, den Server als überwachten Dienst laufen zu lassen – unter systemd oder als Container mit Restart-Policy.

Der unterschätzte Teil ist die Wartung. Ein Konnektor, den du vor einem halben Jahr gebaut und seither nicht angefasst hast, kann durch ein Client-Update stillschweigend brechen. Ein lokal gehosteter Konnektor nimmt dir die Anbieter-Abhängigkeit ab – die Verantwortung für Updates übernimmt er nicht.

Praktische Handlungsempfehlungen August 2026

• Zuerst die Architekturfrage klären: Sollen die Daten das Netz nicht verlassen, ist die Desktop-Erweiterung der Weg – ein Remote-Konnektor setzt einen öffentlich erreichbaren Server voraus.
• Klein und lesend anfangen: ein einziges stdio-Tool, das eine Datei oder einen Status ausliest.
• Vorhandene Hardware nutzen. Für den reinen Konnektor-Betrieb reicht ein Raspberry Pi, ein Mini-PC oder ein LXC-Container auf dem vorhandenen Node.
• Least Privilege von Anfang an: Whitelists für Container und Datenbank-Queries sind Pflicht, kein Extra.
• Bei mehreren internen Diensten den Proxy-Ansatz prüfen: eine Desktop-Erweiterung, die kontrolliert ins interne Netz spricht, statt jeden Server einzeln zu exponieren.
• Logging und Autostart einrichten – systemd oder Container mit Restart-Policy.
• Wartung terminieren: feste Zeitpunkte für SDK-Version, Abhängigkeiten und Funktionsprüfung.

Fazit

Die wichtigste Erkenntnis kommt vor der ersten Codezeile: Ein Remote-Konnektor verbindet sich von Anthropics Cloud aus zu deinem Server – auch dann, wenn du lokal arbeitest. Für Daten, die das Netz nicht verlassen sollen, ist das die falsche Bauform, egal wie bequem sie ist.

Die Desktop-Erweiterung ist die Homelab-Antwort: lokal ausgeführt, über stdio angebunden, ohne offenen Port. Der Preis ist die fehlende Verfügbarkeit auf dem Handy – für mich ein fairer Tausch.

Und der Rat, der den meisten Ärger erspart: klein anfangen, lesend, mit einem einzigen Werkzeug. Wer die Kette einmal sauber zum Laufen gebracht hat, baut den Rest in einem Nachmittag.

Quellen und weiterführende Informationen

• Anthropic Support (support.claude.com) — Grundlagen zu Custom Connectors über Remote-MCP sowie die Abgrenzung, wann Desktop- und wann Web-Konnektoren sinnvoll sind.
• Claude-Dokumentation (claude.com/docs) — Aufbau von Desktop-Erweiterungen, Transport über stdio und die Rolle als Proxy zu internen MCP-Servern.
• Claude Platform Docs (platform.claude.com) — MCP-Connector der API: unterstützte Transporte, Beschränkung auf Tool-Aufrufe und Hinweise zu lokalen Servern.
• Anthropic Engineering (anthropic.com/engineering) — Ankündigung der Desktop-Erweiterungen und die Umstellung der Dateiendung auf .mcpb.
• Model Context Protocol (modelcontextprotocol.io) — Spezifikation, SDKs für Python und TypeScript sowie Referenzimplementierungen.
• Proxmox VE und Home Assistant — offizielle API-Dokumentationen der angebundenen Systeme.
• heise online / c’t (heise.de) — Fachberichterstattung zu MCP, Homelab-Infrastruktur und lokaler KI.

Haftungsausschluss

Allgemeiner Hinweis: Dieser Beitrag auf aimageddon.de schildert eigene Erfahrungen und dient der allgemeinen Information; er ersetzt keine individuelle technische oder rechtliche Beratung. Die beschriebenen Konzepte und Abläufe geben den Stand zum Zeitpunkt der Veröffentlichung wieder — Schnittstellen, SDKs, Client-Versionen und Produktbezeichnungen im KI-Umfeld ändern sich schnell. Maßgeblich ist die jeweils aktuelle offizielle Dokumentation; prüf sie vor eigenen Umsetzungen.

Zu Sicherheit und Betrieb: Ein selbst gebauter Werkzeug-Server erlaubt es einem Sprachmodell, Funktionen auf deiner Hardware auszuführen. Vergib deshalb nur die Rechte, die ein Werkzeug zwingend braucht, validiere alle übergebenen Parameter und betreibe netzwerkfähige Server niemals ungesichert im offenen Internet. Der Betrieb erfolgt auf eigene Verantwortung; für Datenverlust oder Fehlkonfigurationen kann keine Haftung übernommen werden. Wer personenbezogene Daten verarbeitet, bleibt auch bei lokalem Betrieb an die DSGVO gebunden — die lokale Verarbeitung erleichtert die Argumentation, ersetzt aber keine Prüfung der Rechtsgrundlage, der Informationspflichten und der technischen Schutzmaßnahmen.

Zu Anbieterabhängigkeit und Hardware: Cloud-gebundene Werkzeuge und Konnektoren verlieren einen wesentlichen Teil ihrer Funktion, wenn ein Anbieter den Dienst einstellt oder Schnittstellen ändert. Eine lokal kontrollierte Lösung reduziert dieses Risiko, setzt aber eigene Wartung, Sicherheitsupdates und technisches Verständnis voraus. Bestellst du Hardware im Fernabsatz, steht dir nach § 312g BGB ein vierzehntägiges Widerrufsrecht zu; seit dem 19. Juni 2026 müssen Unternehmen dafür nach § 356a BGB eine elektronische Widerrufsfunktion bereitstellen, und § 312k BGB verpflichtet Anbieter laufender Abo-Dienste zu einem gut sichtbaren Kündigungsbutton. Bei Sachmängeln greifen §§ 437 und 438 BGB mit zweijähriger Frist, § 477 BGB kehrt in den ersten zwölf Monaten die Beweislast zugunsten der Käuferseite um.

Affiliate und Marken: Einzelne Links in diesem Beitrag können Affiliate-Links über das Amazon-Partnerprogramm oder das Awin-Netzwerk sein; kaufst du darüber ein, erhält aimageddon.de eine kleine Provision, ohne dass sich der Preis für dich ändert. Alle genannten Markennamen sind eingetragene Warenzeichen der jeweiligen Inhaber und werden ausschließlich zur sachlichen Information verwendet.

👉 Desktop-GPU auf Amazon ansehen

* Produktlinks sind Affiliate-Links. Bei einem Kauf über diese Links erhalten wir eine kleine Provision – für dich entstehen keine Mehrkosten.