MCP mit lokalen Modellen, Werkzeuge ohne Cloud

Ein Sprachmodell allein ist ein Gesprächspartner ohne Hände. Es kann nicht nachsehen, nicht rechnen, nichts abrufen, es kann nur aus dem antworten, was im Gespräch steht. Interessant wird es, wenn es Werkzeuge bekommt, und das Protokoll dafür ist MCP.

Was bei Claude oder ChatGPT selbstverständlich ist, geht auch komplett lokal. Modell auf Deinem Rechner, Werkzeuge auf Deinem Rechner, Daten auf Deinem Rechner. Dieses Playbook zeigt den Weg dahin und sagt an der richtigen Stelle, wo es hakt, weil es an einer Stelle wirklich hakt.

1. Klär, welche drei Teile Du brauchst

Das Protokoll kennt drei Rollen, und die Verwirrung entsteht meistens, weil man sie mit dem Modell durcheinanderwirft.

Der Host ist die Anwendung, in der Du sitzt, etwa Claude Desktop oder eine lokale Weboberfläche. Er startet pro Verbindung einen Client, und jeder Client spricht mit genau einem Server. Der Server stellt die Werkzeuge bereit, etwa Dateizugriff oder eine Datenbank.

Das Modell ist in dieser Aufzählung bewusst nicht dabei. Es ist kein Teilnehmer am Protokoll. Der Host holt sich die Werkzeugliste von den Servern, legt sie dem Modell vor, und wenn das Modell eines aufrufen will, führt der Host den Aufruf aus. Das klingt nach Haarspalterei, ist aber der Grund, warum derselbe Server hinter beliebigen Modellen funktioniert.

Bei Claude Desktop stecken Host und Modellzugang in einer Anwendung. Bei einem lokalen Aufbau trennst Du sie: Ollama liefert das Modell, eine Oberfläche oder ein eigenes Skript ist der Host. Es ist dieselbe Server-Software wie bei Claude, das ist der ganze Punkt eines offenen Protokolls. Welche Server Du in welcher Umgebung tatsächlich einträgst, ist davon unabhängig und eine Sicherheitsfrage, dazu Schritt 10.

Tipp: Wenn Dir das Protokoll selbst noch fremd ist, lies zuerst die Lesson Was ist MCP. Der Rest hier setzt sie voraus.

2. Prüf, ob Dein Modell überhaupt Werkzeuge kann

Nicht jedes lokale Modell beherrscht Tool-Calling. Manche wurden nie darauf trainiert, andere können es nur formal und benutzen es dann falsch. Das ist die erste Hürde, und sie sortiert einen guten Teil der Kandidaten aus.

In der Ollama-Bibliothek sind Modelle mit Werkzeug-Unterstützung entsprechend gekennzeichnet. Halt Dich daran, statt es auszuprobieren und dann eine halbe Stunde lang zu suchen, warum nichts passiert.

Tipp: Nimm für Tool-Calling nicht das kleinste Modell, das Du finden kannst. Unterhalb von etwa sieben Milliarden Parametern fehlt die Fähigkeit weitgehend, dort kommen häufig fehlerhaft formatierte Aufrufe heraus. Darüber entscheidet aber nicht die Größe, sondern ob das Modell gezielt darauf trainiert wurde: in Vergleichstests liegen 8B- und 14B-Modelle mit Tool-Training nah beieinander, während deutlich größere Modelle ohne dieses Training schlechter abschneiden. Größer ist hier also nicht automatisch besser.

3. Nimm eine Oberfläche, die MCP schon kann

Der schnellste Weg führt über eine Oberfläche, die das Protokoll mitbringt. Open WebUI unterstützt MCP nativ seit Version 0.6.31 und ist auf lokale Modelle ausgelegt. Damit sparst Du Dir, den Client selbst zu schreiben.

Der Aufbau ist dann: Ollama läuft im Hintergrund, Open WebUI verbindet sich damit, und in dessen Einstellungen trägst Du Deine MCP-Server ein.

Ein Detail, das beim ersten Versuch fast jeden erwischt: die Server sind dieselben, die Eintragung ist es nicht. Was in Claude Desktop als lokal gestarteter Prozess konfiguriert wird (stdio, also ein Befehl plus Argumente), braucht in einer Weboberfläche eine erreichbare Adresse. Manche Server können beides, andere nur eines.

Wenn Du für einen stdio-Server eine Brücke brauchst, ist das kein reiner Formatwechsel, sondern eine neue offene Tür. Bind sie auf 127.0.0.1, gib ihr ein Zugangstoken, und stell sie nicht ins Netz. Ein per Brücke exponierter Dateiserver ohne Anmeldung ist Dateizugriff für jeden, der die Adresse kennt.

Tipp: Bevor Du einen eigenen Client baust, probier den fertigen. Die meisten merken dabei, dass sie den eigenen gar nicht brauchen.

4. Fang mit einem harmlosen Server an

Nimm als erstes einen Server, der nur liest. Ein Dateizugriff mit Beschränkung auf ein einziges Testverzeichnis ist ideal. Damit siehst Du, ob die Kette funktioniert, ohne dass ein Fehlgriff etwas anrichtet.

Stell dem Modell dann eine Frage, die es ohne das Werkzeug nicht beantworten kann. "Was steht in der Datei notizen.txt" ist ein guter Test, weil die Antwort eindeutig richtig oder falsch ist.

Tipp: Wenn das Modell antwortet, ohne das Werkzeug benutzt zu haben, hat es sich die Antwort ausgedacht. Genau deshalb ist ein Test mit eindeutiger Antwort besser als ein offener.

5. Rechne damit, dass das Modell Werkzeuge übersieht

Hier ist die Stelle, an der lokale Aufbauten sich von Claude unterscheiden, und sie ist wichtiger als alles Technische.

Ein großes Modell entscheidet zuverlässig, wann ein Werkzeug nötig ist. Ein kleines lokales Modell tut das nicht immer. Es antwortet manchmal aus dem Bauch, obwohl das passende Werkzeug bereitsteht. Es ruft manchmal das falsche auf. Und es kann bei einer Kette aus mehreren Schritten den Faden verlieren.

Bevor Du das dem Modell anlastest: es kann auch an der Einrichtung liegen. Ein falsches Chat-Template, ein Server der seine Werkzeuge nicht sauber beschreibt, eine zu grobe Quantisierung, eine Oberfläche die Werkzeug-Aufrufe gar nicht durchreicht. Prüf das zuerst. Bleibt das Verhalten danach, ist es eine Fähigkeitsgrenze des Modells, und die bekommst Du nicht wegkonfiguriert.

Tipp: Je weniger Werkzeuge gleichzeitig aktiv sind, desto zuverlässiger wird die Auswahl. Drei gut beschriebene Werkzeuge schlagen zwanzig, bei kleinen Modellen sehr deutlich.

6. Schreib die Werkzeug-Beschreibungen für ein schwächeres Modell

Bei einem starken Modell darf eine Werkzeug-Beschreibung knapp sein, es versteht den Zusammenhang von selbst. Bei einem lokalen Modell ist die Beschreibung Dein wichtigster Hebel.

Schreib hinein, wann das Werkzeug zu benutzen ist, nicht nur was es tut. Statt "sucht in der Datenbank" also "benutze das, wenn nach einem Kunden, einer Rechnung oder einem Vorgang gefragt wird". Der Unterschied in der Trefferquote ist erheblich.

Tipp: Wenn Du eigene Server baust, ist das ohnehin die bessere Praxis. Die Regeln für gutes Tool-Design stehen in Tool Design, und sie zahlen sich bei lokalen Modellen doppelt aus.

7. Häng Dein Gedächtnis an

Der wertvollste Server in einem lokalen Aufbau ist der, der sich Dinge merkt. Ein kleines Modell weiß wenig über die Welt und noch weniger über Dich. Ein Gedächtnis gleicht beides teilweise aus, weil das Wissen dann nicht im Modell stecken muss, sondern nachgeschlagen wird.

Das ist auch der Punkt, an dem die Größenfrage sich entschärft. Ein 8-Milliarden-Modell mit Zugriff auf Deine Notizen ist bei Fragen zu Deinem Projekt besser als ein großes Modell ohne diesen Zugriff.

Tipp: Genau darum geht es in der Kernthese dieser Academy. Ein Modell, das Deinen Kontext kennt, schlägt ein stärkeres, das raten muss. Der Aufbau steht in Memory einrichten.

8. Halt die schreibenden Werkzeuge kurz an der Leine

Schreibende Werkzeuge sind das offensichtliche Risiko. Ein Modell, das Dateien löschen, Mails senden oder Datensätze ändern kann und gelegentlich das falsche Werkzeug greift, ist eine unangenehme Kombination. Die brauchen eine Bestätigung, immer.

Lesen ist deswegen aber nicht harmlos, und das ist der Fehler, den man in Anleitungen ständig liest. Ein Lesewerkzeug mit zu weitem Zugriff holt SSH-Schlüssel, Zugangsdaten, Steuerunterlagen oder Kundendaten in den Modellkontext, und von dort in Protokolle und Verläufe. Wenn Du später dieselbe Oberfläche einmal gegen ein Cloud-Modell laufen lässt, ist das genau der Weg nach draußen, den Du eigentlich vermeiden wolltest. Dazu kommt: was im Namen "read" heißt, muss nicht nebenwirkungsfrei sein, das Protokoll erzwingt das nicht.

Die Regel ist deshalb nicht "lesen frei, schreiben gesperrt", sondern so wenig Zugriff wie möglich auf beiden Seiten. Gib dem Dateiserver ein einzelnes Verzeichnis statt des Benutzerordners, und lass Dir Schreibaktionen bestätigen.

Tipp: Fang mit einem einzigen Verzeichnis im Lesezugriff an und erweitere erst, wenn Du weißt, was der Aufbau tatsächlich anfasst. Nicht andersherum.

9. Prüf fremde Server, bevor Du sie anschließt

Ein MCP-Server ist ausführbarer Code auf Deinem Rechner. Dass Dein Modell lokal läuft, macht einen fremden Server nicht sicherer. Der Datenschutzgewinn aus dem lokalen Modell ist dahin, wenn der angeschlossene Server nach Hause telefoniert.

Tipp: Der Prüf-Ablauf dafür steht in Fremde MCP-Server sicher prüfen. Bei einem Aufbau, der ausdrücklich wegen Datenschutz lokal ist, ist dieser Schritt nicht optional.

10. Entscheide ehrlich, ob es reicht

Nach einer Woche im Alltag weißt Du, ob der Aufbau trägt. Zwei Ergebnisse sind normal und beide in Ordnung.

Entweder es reicht, dann hast Du einen Assistenten mit Werkzeugen, bei dem nichts das Haus verlässt. Oder es reicht nicht, weil das Modell zu oft danebengreift. Dann ist die Antwort nicht "lokal taugt nichts", sondern ein gemischter Aufbau: das Lokale für alles mit sensiblen Daten, das große Modell für die schweren Fälle.

Dabei gilt aber genau das, wovor Schritt 8 warnt. Wenn Du im selben Profil zwischen lokalem und Cloud-Modell hin- und herschaltest, gehen die Werkzeuge und der bisherige Verlauf mit, und damit auch alles, was ein Lesewerkzeug vorher hereingeholt hat. Trenn deshalb auf der Ebene, die wirklich trennt: zwei getrennte Installationen beziehungsweise getrennte Konfigurationsverzeichnisse. Ein zweites Fenster reicht nicht, und ein zweites Benutzerprofil in derselben Oberfläche auch nicht: die MCP-Server und die Modell-Zugänge sind dort in aller Regel global hinterlegt, also aus beiden Profilen erreichbar. In der lokalen Installation stehen die sensiblen Server und kein Cloud-Zugang; in der anderen steht der Cloud-Zugang und diese Server stehen dort schlicht nicht drin.

Tipp: Dass ein MCP-Server auf beiden Seiten laufen KÖNNTE, heißt nicht, dass er es soll. Die Portabilität spart Dir die Einarbeitung beim Aufsetzen der zweiten Umgebung, nicht die Entscheidung, welche Server dort überhaupt eingetragen werden. Mehr zum Prinzip in Tool-Portabilität.

Was als nächstes

Wenn das Modell selbst noch fehlt, fang mit Dein erstes lokales KI-Modell in 30 Minuten an. Die Größenfrage klärt Welches lokale Modell zu Deiner Hardware passt. Und wenn Du irgendwann einen eigenen Server bauen willst, statt fremde anzuschließen, ist Level 6 mit MCP-Server planen der Einstieg.

Source

• Model Context Protocol, offizielle Spezifikation: https://modelcontextprotocol.io
• Ollama, Modelle mit Werkzeug-Unterstützung: https://ollama.com/search?c=tools
• Open WebUI, Dokumentation zur MCP-Anbindung: https://docs.openwebui.com