Ein Endpunkt für jeden Agenten statt 20 MCP-Konfigurationen pro Repository.

Hintergrund

Das Plattform-Team betreute rund sechzig Ingenieure in einem Dutzend Produkt-Squads. Im ersten Jahr der MCP-Einführung hatte jede Squad ihre eigenen Server — GitHub, Postgres, Linear, Sentry, ein internes Deploy-Werkzeug — direkt in die Konfigurationen von Claude Code und Cursor verdrahtet. Jedes Repository trug seine eigene mcp.json, und ein neues Werkzeug einzuführen bedeutete einen Pull Request gegen jedes Projekt, das es haben wollte.

Der Aufbau funktionierte, skalierte aber nicht. Rund zwanzig Server lagen nun in Dutzenden Konfigurationsdateien dupliziert vor, jeweils mit leicht abweichenden Versionen und Zugangsdaten, die derjenige eingefügt hatte, der es zuerst eingerichtet hatte.

Die Herausforderung

Drei Probleme kamen in jeder Retrospektive wieder auf.

• Konfigurations-Wildwuchs. Einen Server hinzuzufügen oder zu aktualisieren, hieß, jedes Repository anzufassen. Die Konfigurationen drifteten auseinander, und niemand konnte mit Sicherheit sagen, welche Squad über welche Werkzeuge verfügte.
• Zugangsdaten am falschen Ort. Persönliche Access-Tokens und API-Schlüssel lagen auf den Rechnern der Entwickler und mitunter in eingecheckter Konfiguration. Ein kompromittiertes Token zu rotieren, glich einer Schnitzeljagd.
• Ein überfülltes Kontextfenster. Jeder MCP-Server schob sein vollständiges Tool-Schema bei jeder Anfrage in den Prompt. Mit zwanzig verbundenen Servern verbrauchte der Agent einen großen Teil seines Kontexts für Tool-Definitionen, noch bevor er die erste Zeile der eigentlichen Aufgabe sah.

Der Ansatz

Das Team richtete ein einziges onemcp-Portal ein, fügte seine Server einmalig dort hinzu und authentifizierte jeden Upstream direkt an Ort und Stelle. Statt dass jeder Client mit jedem Server spricht, sprechen die Clients nun mit dem Portal, und das Portal verteilt an die Upstreams.

Zwei Dinge veränderten die Gestalt des Problems:

• Ein Endpunkt ersetzt viele. Ein Repository listet keine Server mehr auf; es richtet Claude Code oder Cursor auf die Portal-URL und erbt das gesamte kuratierte Werkzeug-Set. Einen Server zu tauschen oder zu aktualisieren, geschieht einmal, im Portal.
• Code Mode ersetzt die Wand aus Definitionen. Statt jedes Tool-Schema vorab einzuspeisen, stellt das Portal nur drei Meta-Tools bereit — search, describe und execute. Der Agent findet bei Bedarf die wenigen Werkzeuge, die eine Aufgabe erfordert, und ruft sie aus einem einzigen Skript in einem Roundtrip auf.

Die Einführung

Die Migration verlief Squad für Squad über zwei Wochen. Für jedes Repository löschte das Team die lokale Serverliste und setzte einen einzigen Portal-Eintrag ein. Da das Portal die Zugangsdaten hält, entfernten die Entwickler dabei zugleich die Tokens von ihren Rechnern.

Das Plattform-Team behielt das Portal als einzigen Kontrollpunkt: Neue Server wurden zentral geprüft und hinzugefügt, und Zugriffe an einer Stelle verwaltet, statt über Dutzende mcp.json-Dateien verstreut.

Die Ergebnisse

• Über 20 Server hinter einem Endpunkt. Die Repositories verweisen auf eine einzige Portal-URL. Ein Werkzeug hinzuzufügen ist eine Portal-Änderung, kein flottenweiter Pull Request.
• Tool-Overhead pro Anfrage um rund 90 % gesenkt. Hunderte vorab geladener Definitionen durch drei Meta-Tools zu ersetzen, senkte den Tool-Overhead pro Anfrage von etwa 15.000 Tokens auf rund 500 — Kontext, den die Agenten nun der Aufgabe widmen.
• Zugangsdaten hostseitig. Upstream-OAuth und Tokens verbleiben im Portal, nie in Client-Konfigurationen oder eingecheckten Dateien. Die Rotation ist eine Aktualisierung an einer Stelle.

Wir liefern MCP-Konfiguration nicht mehr in Pull Requests aus. Heute zeigt ein Repository auf einen Endpunkt und erhält alles, und die Tokens verwaltet die Security statt uns.

Verwandte Fallstudien

• Ein KI-Support-Agent auf Token-Diät
• Self-Service-Datenagenten, ohne Zugangsdaten preiszugeben