Wie Agenturen jeden Kunden-Stack durch ein MCP Gateway fahren

Ein MCP Gateway für Agenturen löst ein Problem, das In-house-Teams nie treffen: Derselbe Agent muss über viele Kunden-Stacks arbeiten, ohne sie zu vermischen. Du verbindest die Tools jedes Kunden einmal, fährst die Arbeit über einen Endpunkt und nimmst den Zugriff an dem Tag zurück, an dem das Mandat endet.

Der letzte Teil zählt mehr, als er klingt. Agenturen onboarden und offboarden ständig, und jedes Offboarding ist ein Sicherheitsereignis.

Viele Kunden, viele Stacks, dieselben fünf Aufgaben

Agenturarbeit ist repetitiv über Kunden hinweg und fragmentiert über Tools. Der Monatsreport ist derselbe Job, ob der Kunde HubSpot oder Pipedrive fährt. Das Kampagnen-Setup ist derselbe Job, egal in welchem Workspace das Werbekonto liegt. Was sich pro Kunde ändert, sind Stack, Zugangsdaten und Kontext: Namenskonventionen, Konto-IDs, was beim Kickoff vereinbart wurde.

Rechne es für ein mittleres Kundenbuch durch. Zehn Kunden mit je fünf verbundenen Tools sind 50 Credentials. Ohne Gateway leben diese 50 Keys in Prompt-Dateien, Env-Dateien und einem geteilten Doc, das jemand in Eile angelegt hat. Jeder neue Kunde bringt fünf dazu. Jeder Abgang heißt fünf Keys finden und hoffen, dass du jede Kopie erwischt hast.

Ein Gateway kollabiert das. Die Tools jedes Kunden verbinden sich einmal, per OAuth oder mit einem API-Key, der in einen Vault wandert, und der Agent spricht mit einem einzigen Endpunkt. Die rohen Keys reisen nie im Prompt mit, und KI-Agenten in der Kundenarbeit hören auf, ein Verteilmechanismus für Zugangsdaten zu sein.

Was ein MCP Gateway für Agenturen leisten muss

Vier Anforderungen, in der Reihenfolge, in der sie beißen:

• Eine Grenze pro Kunde. Verbindungen nach Mandat gruppiert, Tools namespaced, damit der Agent das CRM des einen Kunden nicht mit dem des anderen verwechseln kann. Ein Endpunkt darf nicht ein undifferenzierter Tool-Haufen heißen.
• Widerrufbarer Zugriff. Endet ein Mandat, widerrufst du die Verbindungen dieses Kunden an einer Stelle. Keine Key-Rotation über fünf Dienste, keine Archäologie in alten Configs.
• Ein Audit-Trail. Wenn ein Kunde fragt, was der Agent letzten Dienstag in seinem CRM geändert hat, ist "wir glauben nichts" keine Antwort. Ein Log pro Aufruf schon. Warum der Audit-Trail die erste Forderung an jedes Agenten-Setup ist, steht in [Audit-Trails für KI-Agenten](/de/blog/ai-agent-audit-trail).
• Memory, die die Grenze respektiert. Kunden-Kontext soll Sessions überleben, und er darf nie von einem Kunden in den anderen bluten.

Die ersten drei lösen die Sicherheits-Hälfte der Agenturarbeit. Die vierte löst die Ökonomie.

Die Neu-Lern-Steuer, multipliziert mit deiner Kundenzahl

Ein Agent ohne persistente Memory startet jede Kunden-Session bei null: Welcher Workspace ist das, welche Konto-IDs zählen, in welchem Format will dieser Kunde den Report, was haben wir letzten Monat zur Attribution entschieden. Er holt und leitet alles neu her, und du zahlst Tokens für jede Wiederholung.

Ein In-house-Team zahlt diese Steuer einmal, für einen Stack. Eine Agentur zahlt sie pro Kunde, pro Session. Zwölf Kunden mit je einer Session pro Woche sind grob 48 Kaltstarts im Monat, bevor irgendeine abrechenbare Arbeit passiert.

Das ist der stille Preis der Agentur-Automatisierung: MCP gibt dem Agenten Hände, aber ohne Memory hat er Amnesie über jeden Kunden, den er betreut. Eine [Memory-Schicht](/de/blog/memory-layer-for-ai-agents) ändert die Form der Session. Der Agent ruft IDs, Konventionen und stehende Entscheidungen des Kunden ab, statt sie neu zu etablieren, und die Arbeit beginnt bei der eigentlichen Aufgabe. Eine Zahl zu den Ersparnissen nennen wir nicht, wir messen echte Werte in unserer Beta, statt eine zu erfinden, aber die Mechanik ist schlicht: weniger Wiederholungen, weniger abgerechnete Tokens.

Wo Tulimoa passt, und wo noch nicht

Volle Transparenz: Tulimoa ist unser Produkt, ein MCP Gateway in früher Beta. Hier der ehrliche Fit.

Was gebaut ist: ein Endpunkt, der deine verbundenen MCP-Server hinter einer namespaced Tool-Liste bündelt, ein verschlüsselter Credential-Vault pro Geheimnis, jederzeit widerrufbare Verbindungen, ein Audit-Trail für jeden Aufruf und eine Memory-Schicht (remember, recall, checkpoint, set_goal), die auf jedem Plan kostenlos ist. Wir sind eine EU-Firma, gebaut in Deutschland, gehostet in der EU.

Was noch fehlt: Das Gateway ist heute nicht self-serve, es gibt keinen öffentlichen Anmelde-Flow, du kommst über das Dashboard in die Beta. Und jeder Plan erlaubt aktuell einen verbundenen Agenten, mehr kommt. Wenn deine Agentur morgen einen Agenten pro Account-Manager will, sind wir das noch nicht, und wir sagen es dir lieber jetzt.

Eine Sache ist heute live und kostenlos: [das Agentur-Partnerprogramm](/de/for-agencies). Wenn du MCP-Tooling für Kunden aufsetzt, kannst du deren Tools stellvertretend im Tulimoa-Verzeichnis einreichen, und der Kunde übernimmt das Listing danach. Listen ist kostenlos, und das Partnerprogramm kostet während der Beta nichts.

Wo du anfängst

Schritt 1: Inventarisiere deine Credentials. Kunden mal verbundene Tools. Die Zahl ist meist höher, als irgendjemand im Raum geschätzt hat.

Schritt 2: Nimm den Kunden mit dem unordentlichsten Stack und route zuerst nur dieses Mandat durch ein Gateway. Die [Gateway-Seite](/de/gateway) zeigt, wie Verbindungen, Widerruf und Memory zusammenspielen.

Schritt 3: Schreib die Offboarding-Checkliste, bevor du sie brauchst. Wenn der Widerruf eines scheidenden Kunden mehr als einen Screen kostet, ist das Setup durchgefallen.

Arbeitest du solo statt im Team, hat dasselbe Problem eine andere Form: weniger Kunden, aber du bist auch die gesamte Sicherheitsabteilung. Das steht in [der Berater-Version dieses Beitrags](/de/blog/mcp-gateway-for-consultants).