Die MCP-Server, die ich wirklich täglich nutze — und die, die ich gelöscht habe
Eine ehrliche Inventur meines Agenten-Setups: welche MCP-Server einen festen Platz verdient haben, welche binnen einer Woche rausflogen und die eine Regel, die beides trennt.
Ich arbeite inzwischen seit einer Weile hauptsächlich mit KI-Coding-Agenten, und das, was sich am meisten verändert hat, ist nicht das Modell. Es ist die Installation drumherum — die MCP-Server, über die ein Agent meine echten Werkzeuge anfassen kann, statt nur über sie zu reden.
Ich habe viele davon installiert. Die meisten flogen innerhalb einer Woche wieder raus. Das hier ist die ehrliche Inventur: was geblieben ist, was ging, und die Regel, die beides trennt.
Was geblieben ist
Mein eigenes Notizsystem. Alles, was ich lese, schaue oder mir erarbeite, landet über einen kleinen selbstgeschriebenen MCP-Server an einem Ort. Diesen würde ich am meisten vermissen — nicht wegen des Schreibens, sondern wegen des Lesens. Wenn ich eine Session zu einem Projekt starte, das ich einen Monat nicht angefasst habe, holt sich der Agent seinen Kontext selbst, statt dass ich ihn neu erkläre. Darin liegt der ganze Wert.
Ein Server für persönliche Daten. Gewicht, Schlaf, Mahlzeiten, Abos, Domains, Vermögen. Aufgeschrieben klingt das übertrieben. In der Praxis heißt es, dass Fragen wie „welche Domains laufen in den nächsten zwei Monaten aus“ oder „was habe ich dieses Quartal wirklich für Tools ausgegeben“ eine einzeilige Antwort haben statt einer Tabellenexpedition.
Projekte und Aufgaben. Mein eigenes Produkt- und Task-System, über MCP zugänglich. Der Agent sieht, was ein Projekt ist, was blockiert ist und welche Abnahmekriterien gelten. Ohne das beginnt jede Session damit, dass ich denselben Kontext einfüge.
Ein Headless CMS. Der Überraschungssieger, gemessen an der Nutzung. Einen Blogartikel aus dem Terminal zu veröffentlichen — inklusive korrekt verknüpfter Übersetzungen in vier Sprachen — ist eine Fünf-Minuten-Aufgabe statt eines Nachmittags voller Copy-Paste. Alle meine Websites beziehen ihre Inhalte inzwischen daraus.
Design- und Browserzugriff. Figma, um echte Komponentenspezifikationen zu ziehen statt zu raten, und Browsersteuerung für Dinge, die nur hinter einem Login existieren. Beides nutze ich selten, aber wenn, dann unersetzlich.
Buchhaltung. Rechnungen, Ausgaben, Kontakte. Sehr langweilig. Spart jeden Monat eine Stunde, und das ist die richtige Art von Langeweile.
Was ich gelöscht habe
Alles, was riesige Datenblöcke zurückgibt. Killer Nummer eins. Ein Server, dessen „list“-Aufruf jedes Feld jedes Datensatzes liefert, verbrennt das Kontextfenster mit einem einzigen Call und produziert nichts Brauchbares. Genau das ist mir heute passiert: ein völlig sauber gebauter CMS-Aufruf lieferte 330.000 Zeichen, weil er die vollständigen Texte von fünfzig Beiträgen enthielt. Das Werkzeug war nicht falsch — es wurde nur entworfen, ohne daran zu denken, wer die Ausgabe liest.
Alles mit vierzig Tools. Große Werkzeugflächen machen den Agenten schlechter, nicht besser. Er verbraucht seine Aufmerksamkeit mit der Wahl zwischen fast identischen Optionen. Die Server, die geblieben sind, bieten zwischen fünf und zwanzig fokussierte Tools.
Wrapper um Dinge mit gutem CLI. Wenn ein Werkzeug aus der Shell gut funktioniert, fügt ein MCP-Wrapper vor allem eine Zwischenschicht hinzu. git, ffmpeg, yt-dlp — die lasse ich den Agenten direkt aufrufen.
Alles mit interaktiver Anmeldung, die abläuft. Ein Server, für den ich mich im Browser neu anmelden muss, ist ein Server, der genau dann kaputt ist, wenn etwas unbeaufsichtigt läuft.
Die Regel
Nach genügend Versuchen wurde es einfach: Ein MCP-Server verdient seinen Platz, wenn er Zustand zugänglich macht, den der Agent sonst nicht sieht — in Portionen, die klein genug zum Lesen sind.
Beide Hälften zählen.
Zustand, den der Agent nicht sieht, heißt: meine Notizen, meine Projekte, meine Zahlen, die Inhalte meiner Kunden. Keine Dokumentation — die findet er selbst. Keine Befehle — er hat eine Shell.
Klein genug zum Lesen heißt: Die Ausgabe ist für einen Leser mit begrenztem Kontextfenster entworfen. Standardmäßig Zusammenfassungen. Details auf Anfrage. IDs statt eingebetteter Objekte. Es ist genau die Disziplin einer gut entworfenen API — und die meisten MCP-Server sind geschrieben, als hätte der Konsument unendlich Geduld.
Was ich jemandem raten würde, der damit anfängt
Fangen Sie mit einem an. Nehmen Sie das System, aus dem Sie am häufigsten Kontext kopieren — bei den meisten sind das Notizen oder der Task-Tracker — und binden Sie das an. Leben Sie eine Woche damit, bevor Sie ein zweites hinzufügen.
Achten Sie dann auf das typische Versagen. Wenn eine Session schlecht läuft, prüfen Sie, ob der Agent etwas Riesiges lesen musste, um eine kleine Frage zu beantworten. Das ist ein Designproblem des Servers, kein Modellproblem — und es ist behebbar: Parameter ergänzen, weniger zurückgeben, paginieren.
Und halten Sie die Gesamtzahl klein. Mein Setup hat unter zehn Server, und am besten laufen die Sessions, in denen der Agent genau den Zugriff hat, den die Aufgabe braucht, und sonst nichts.
Die interessante Verschiebung ist nicht, dass Agenten Code schreiben können. Sie ist, dass sie inzwischen dieselben Systeme sehen wie ich. Wie gut das ist, was sie sehen, ist reine Designfrage — und die liegt bei mir.