MCP Router: eine Desktop-Zentrale für lokale und entfernte MCP-Server

Das Problem: viele Server, viele Clients, keine gemeinsame Sicht

Ein einzelner MCP-Server ist schnell eingerichtet. Sobald mehrere Server auf mehrere Clients verteilt sind, entsteht ein Verwaltungsproblem. Jeder Client hält seine eigene Konfiguration, jeder Server bringt eigene Tools mit, und Zugangsdaten liegen an mehreren Stellen. MCP Router setzt an dieser Stelle an und beschreibt sich selbst als Desktop-Anwendung, die die Verwaltung von MCP-Servern vereinfacht. Die Zielgruppe sind Nutzer, die bereits mehrere MCP-Server betreiben und diese nicht mehr einzeln pro Client pflegen wollen. Der Anspruch ist ausdrücklich breit: laut README lassen sich entfernte und lokale Server verbinden, und die Server können über DXT, JSON oder manuell hinzugefügt werden. Wer nur einen einzigen Server in einem einzigen Client nutzt, hat kein Problem, das dieses Werkzeug löst.

Projekte und Workspaces als eigentliche Struktur

Die interessanteste Designentscheidung ist die Aufteilung in zwei Ebenen. Projekte bündeln MCP-Server zu einer Gruppe, Workspaces funktionieren laut README wie Browser-Profile und verwalten Modi. Dazu kommt ein Schalter auf der untersten Ebene: einzelne Tools lassen sich pro Server ein- und ausschalten. Das ist mehr als eine Oberfläche über vorhandenen Konfigurationsdateien, denn es verschiebt die Auswahl des Tool-Umfangs in die Anwendung. Der Nutzen liegt auf der Hand, wenn ein Server Dutzende Tools mitbringt und nur wenige davon in einem bestimmten Kontext gebraucht werden. Der Preis ist ebenso klar: die Auswahl liegt nicht mehr in der Konfiguration des Clients, sondern in MCP Router. Wer die Tool-Auswahl versionieren oder im Repository mitführen will, muss diesen Zustand dann aus der Anwendung heraus pflegen.

Der Datenfluss läuft über einen lokalen Router

MCP Router ist kein Server, der Tools selbst bereitstellt. Die Anwendung sitzt zwischen Client und MCP-Server und leitet Anfragen weiter. Sichtbar wird das an der Einbindung: nach der Einrichtung verbindet sich ein Client über die CLI mit MCP Router, und beim Hinzufügen einer eigenen Anwendung wird ein Token ausgegeben, das als MCPR_TOKEN gesetzt wird. Der Client spricht also nicht mehr direkt mit dem jeweiligen MCP-Server, sondern mit der Router-Instanz, die die konfigurierten Server kennt. Das erklärt auch, warum die Anwendung plattformgebunden ist: das README nennt Windows und macOS als unterstützte Systeme. Für Linux gibt es in der Materialbasis keinen Hinweis auf einen Build.

Inbetriebnahme über Token und CLI

Die Installation erfolgt laut README über die Releases-Seite, also über ein herunterladbares Paket und nicht über einen Paketmanager. Danach wird der Token gesetzt, der beim Hinzufügen einer eigenen Anwendung ausgegeben wird:

export MCPR_TOKEN="mcpr_your_token"

Der Verbindungsaufbau läuft über npx:

npx -y @mcp_router/cli connect

Soll ein bestimmtes Projekt verwendet werden, kommt ein Argument hinzu:

npx -y @mcp_router/cli connect --project <project-name>

Das ist der gesamte dokumentierte Einrichtungsweg. Wer nach Konfigurationsschlüsseln für Server sucht, findet im README keine. Die Server werden über die Oberfläche hinzugefügt, nicht über eine Datei, die man von Hand schreibt. Für reproduzierbare Setups ist das ein Nachteil, weil sich der Zustand nicht ohne Weiteres in ein Repository einchecken lässt.

Was das README nicht beantwortet

Die Dokumentation ist an mehreren Stellen dünn. Es gibt keine Angabe dazu, welches Transportverfahren zwischen Client und Router verwendet wird, ob also stdio, HTTP oder beides unterstützt wird. Ebenso fehlt jede Aussage zur Fehlerbehandlung: was passiert, wenn ein konfigurierter Server beim Start nicht erreichbar ist, ob der Router dann Anforderungen ablehnt oder den betroffenen Server stillschweigend ausblendet. Auch zur Frage, wie mehrere Clients gleichzeitig angebunden werden und ob der Token pro Client gilt, sagt das Material nichts. Die Logs sind als Screenshot abgebildet, aber ohne Beschreibung des Formats oder der Aufbewahrungsdauer. Wer den Router als dauerhaft laufende Komponente einplant, muss diese Punkte vorher selbst klären, weil sie sich aus der Materialbasis nicht beantworten lassen.

Alternative: die Konfigurationsdateien der Clients

Die naheliegende Alternative ist, auf MCP Router zu verzichten und die MCP-Server direkt in den Konfigurationsdateien der jeweiligen Clients zu hinterlegen. Der Unterschied liegt nicht im Funktionsumfang, sondern in der Anzahl der beweglichen Teile. Ohne Router spricht der Client direkt mit dem Server. Es gibt keine zusätzliche Instanz, die laufen muss, keinen Token, der erneuert werden kann, und keinen Zustand in einer grafischen Anwendung. Dafür muss jede Änderung an jedem Client einzeln nachgezogen werden, und eine gemeinsame Übersicht über aktive Tools existiert nicht. MCP Router lohnt sich genau dann, wenn dieser Abgleich der aufwendigere Teil ist. Bei einem oder zwei Clients ist er es nicht.

Lizenz und Wartung

Die Lizenz ist der Punkt, der vor einer Adoption geklärt werden muss. Das Repository gibt als Lizenzbezeichner NOASSERTION an, das README verweist auf eine Sustainable Use License und auf die Datei LICENSE.md. Diese Kombination bedeutet, dass der Bezeichner nicht maschinell ausgewertet werden konnte und die Bedingungen im Einzelfall zu lesen sind. Eine Sustainable Use License ist typischerweise keine anerkannte Open-Source-Lizenz im Sinne der OSI, sondern schränkt die kommerzielle Nutzung ein. Ob der geplante Einsatz davon erfasst wird, lässt sich aus dem Material nicht ableiten und ist keine Frage, die dieser Artikel beantworten kann. Zur Wartung: die letzten drei Releases liegen bei v0.6.3 (Juni 2026), v0.6.2 (Januar 2026) und v0.6.1 (November 2025). Der Abstand zwischen v0.6.1 und v0.6.2 beträgt rund zwei Monate, zwischen v0.6.2 und v0.6.3 rund fünf. Die Versionsnummern bleiben im 0.6er-Bereich, es gibt also keinen Hinweis auf eine stabile 1.0. Wer den Router produktiv einsetzt, plant am besten damit, dass sich die Oberfläche und das Token-Verhalten zwischen Minor-Versionen ändern können.

Redaktionelles Fazit

Wer viele MCP-Server gleichzeitig in mehreren Clients betreibt und den Überblick über Tools und Zugangsdaten verloren hat, findet hier eine grafische Verwaltungsschicht, die laut README alle Daten lokal hält. Wer MCP-Server ausschließlich projektspezifisch konfigurieren will, sollte stattdessen bei den Konfigurationsdateien der Clients bleiben, denn MCP Router setzt eine zweite Instanz zwischen Client und Server. Vor dem Einsatz zu klären sind zwei Dinge: ob die Sustainable Use License den geplanten Einsatz in einem kommerziellen Produkt erlaubt, und ob der Client, der angebunden werden soll, den Token-Workflow aus dem README unterstützt.

Offizielle Quellen

1. Issues
2. mcp-router/mcp-router on GitHub
3. Project website
4. README
5. Releases