Als wir bei StudioMeyer den ersten MCP Server gebaut haben, hatte er drei Tools. Heute betreiben wir 58 MCP Server mit über 680 Tools -- ein System, das unsere gesamte Geschaeftslogik abbildet, von CRM über Billing bis hin zu Video-Produktion und Website-Analyse. Dieser Artikel ist die technische Geschichte dahinter: Wie baut man eine MCP-Infrastruktur, die skaliert, ohne zu kollabieren?
Der Anfang: Ein Server, drei Tools
Jedes große System startet klein. Unser erster MCP Server war ein CRM-Tool mit drei Funktionen: Kontakt anlegen, Kontakt suchen, Kontakt aktualisieren. TypeScript, Zod-Schemas für Input-Validierung, ein Handler pro Tool. Simpel, funktional, nuetzlich.
Aber sobald ein System funktioniert, wachsen die Anforderungen. "Kannst du auch Rechnungen erstellen?" "Wir brauchen ein Monitoring." "Die Outreach-Mails sollten auch über MCP laufen." Jede Anforderung bedeutete: neue Tools, neue Schemas, neue Handler. Und hier wurde klar: Ein einzelner Server mit 680 Tools wuerde nicht funktionieren.
Die 3-Tier-Architektur
Die Lösung war eine Architektur, die Tools nach Zugriffslevel und Verantwortung trennt. Drei Ebenen, klar definiert:
Tier 1: Interne Server
Tier-1-Server sind ausschließlich für unsere eigene Infrastruktur. Sie laufen lokal, kommunizieren über stdio (Standard Input/Output) und sind nie öffentlich erreichbar. Hier liegen die Tools, die direkt mit unserer Datenbank, unseren Servern und unseren internen Prozessen arbeiten.
Beispiele:
- Nex Intelligence -- Unser Memory-System. Speichert Entscheidungen, Learnings, Patterns. Über 300 Eintraege, durchsuchbar per KI.
- Deploy (8 Tools) -- Container-Management, Deployments, Rollbacks. Direkter Docker-Zugriff, deshalb strikt intern.
- Monitor (9 Tools) -- Service-Health, Container-Status, Resource-Monitoring. Liest Docker-Stats und System-Metriken.
Tier 2: Geteilte Server
Tier-2-Server werden sowohl intern als auch von unseren Agent-Systemen genutzt. Sie bieten Dual Transport: stdio für lokale Nutzung, HTTP für Agent-Zugriff. Diese Server kapseln Geschaeftslogik, die von mehreren Systemen benötigt wird.
Beispiele:
- CRM (25 Tools) -- Kontakte, Deals, Pipeline, Lead-Scoring, Tags, Notizen, Aktivitaeten, Suche. Der umfangreichste Server im System.
- Billing (17 Tools) -- Rechnungen, Zahlungen, Abonnements, Stripe-Integration, Mahnwesen.
- Outreach (10 Tools) -- E-Mail-Sequenzen, Follow-ups, Lead-Generierung, Template-Management.
- Onboard (5 Tools) -- Kunden-Onboarding-Workflows, Meilenstein-Tracking, Checklist-Management.
- Audit -- Code-Qualitaet, Security-Scans, Compliance-Pruefungen.
Tier 3: Kundenfaehige Server
Tier-3-Server sind so gebaut, dass sie als eigenstaendige Produkte funktionieren können. Sie haben saubere APIs, vollstaendige Dokumentation und können von Kunden als MCP Server in ihren eigenen Assistenten eingebunden werden.
Beispiele:
- Media -- Video-Generierung (via Replicate/Minimax), Bild-Generierung (DALL-E), n8n-Workflow-Integration.
- Video -- Website-Recording, Scroll-Capture, Multi-Device-Recording, Text-to-Speech, Post-Production.
- Effects -- Animation-Extraktion von Live-Websites. Hover-States, GSAP-Timelines, Scroll-Triggers, SVG-Pfade, Lottie-Animationen.
- Generate -- CSS-Keyframes, GSAP-Animationen, Scroll-Effekte, WebGL-Shader, Three.js-Szenen, Particle-Systeme.
- Website -- Website-Analyse, Screenshot, DOM-Extraktion, Component-Erkennung, HTML-zu-React-Konvertierung.
- Social -- Social-Media-Content erstellen, Carousels, Stories, Brand-Kit-Management.
Die Technik: TypeScript, Zod und Dual Transport
Jeder MCP Server folgt demselben Pattern. Das macht die Architektur vorhersagbar und wartbar, egal ob der Server 5 oder 50 Tools hat.
Zod-Schemas für alles
Jedes Tool-Input wird durch ein Zod-Schema definiert. Keine any-Types, keine optionalen Validierungen. Wenn ein Parameter falsch ist, schlägt das Schema fehl -- bevor der Handler überhaupt läuft.
const createContactSchema = z.object({
name: z.string().min(1),
email: z.string().email(),
company: z.string().optional(),
tags: z.array(z.string()).default([])
});
Das ist nicht nur Typsicherheit -- es ist Dokumentation. Der KI-Assistent liest das Schema und weiss exakt, welche Parameter erwartet werden, welche optional sind und welche Formate gelten.
Dual Transport: stdio + HTTP
Unsere Shared-Library (@studio-mcp/shared) bietet startDualTransport() -- eine Funktion, die jeden MCP Server sowohl über stdio als auch über HTTP verfuegbar macht.
stdio wird verwendet, wenn der Agent den Server als Subprocess startet. Direkt, schnell, keine Netzwerk-Latenz. Ideal für lokale Entwicklung und Tier-1-Server.
HTTP wird verwendet, wenn Agents über das Netzwerk auf den Server zugreifen. Jeder Tier-2- und Tier-3-Server hat einen dedizierten Port:
| Server | Port |
|---|---|
| CRM | 4001 |
| Billing | 4002 |
| Monitor | 4003 |
| Deploy | 4004 |
| Outreach | 4005 |
| Onboard | 4006 |
| Audit | 4007 |
Die Aktivierung erfolgt über ein --http Flag oder die Umgebungsvariable MCP_HTTP=1. Auf Agent-Seite wechselt MCP_TRANSPORT=http die Konfiguration automatisch.
Server Factory Pattern
Für HTTP-Sessions nutzen wir ein Factory Pattern: createMcpServer() erzeugt für jede HTTP-Session eine frische Server-Instanz. Kein geteilter State zwischen Sessions, kein Memory-Leak, keine Race Conditions.
Warum modular?
Die Versuchung ist groß, alles in einen Server zu packen. Ein Server, alle Tools, fertig. Aber das skaliert nicht -- aus mehreren Gruenden:
Toolsprawl: Ein Assistent mit 680 Tools gleichzeitig ist ueberfordert. Er weiss nicht, welches Tool wann relevant ist. Die Qualitaet der Tool-Auswahl sinkt drastisch ab etwa 30-40 Tools pro Kontext.
Verantwortung: Wenn der Billing-Server einen Bug hat, ist nur Billing betroffen. Nicht das CRM, nicht das Monitoring, nicht die Website-Analyse.
Security: Nicht jeder Agent braucht Zugriff auf alles. Der Sales-Agent hat keinen Deploy-Zugriff. Der DevOps-Agent hat keinen CRM-Zugriff. Least Privilege by Design.
Skalierung: Jeder Server kann unabhängig skaliert werden. Wenn das CRM unter Last steht, skalieren wir den CRM-Server -- nicht das gesamte System.
Die Zahlen
58 MCP Server. 680+ Tools. Alles in TypeScript, alles mit Zod-Schemas, alles mit Dual Transport. Aber Zahlen allein sagen wenig. Was zaehlt: Jedes Tool loest ein konkretes Problem. Kein Tool existiert als Demo oder Placeholder.
Die komplette Server-Liste:
| Server | Tools | Tier | Funktion |
|---|---|---|---|
| CRM | 25 | 2 | Kundenmanagement |
| Billing | 17 | 2 | Rechnungen & Zahlungen |
| Monitor | 9 | 2 | Service-Ueberwachung |
| Deploy | 8 | 1 | Container-Management |
| Outreach | 10 | 2 | E-Mail & Lead-Gen |
| Onboard | 5 | 2 | Kunden-Onboarding |
| Audit | Variabel | 2 | Qualitaet & Compliance |
| Media | Variabel | 3 | Video & Bild-Generierung |
| Video | Variabel | 3 | Website-Recording & TTS |
| Effects | Variabel | 3 | Animation-Extraktion |
| Generate | Variabel | 3 | Code-Generierung |
| Website | Variabel | 3 | Website-Analyse |
| Social | Variabel | 3 | Social-Media-Content |
| Nex | Variabel | 1 | Memory & Intelligence |
Was Sie daraus lernen können
Wenn Sie eigene MCP Server bauen wollen, hier die Lektionen aus unserer Erfahrung:
- Klein starten. Ein Server, drei Tools, ein Problem loesen. Dann erweitern.
- Zod-Schemas sind Pflicht. Nicht optional, nicht "später." Vom ersten Tool an.
- Modular denken. Ein Server pro Domaene, nicht ein Server für alles.
- Dual Transport von Anfang an. stdio für Entwicklung, HTTP für Produktion. Beides implementieren, bevor Sie es brauchen.
- Factory Pattern für HTTP. Kein geteilter State. Jede Session bekommt eine frische Instanz.
Die Tools, die auf dieser Architektur laufen, finden Sie in unserem Store -- einzeln oder als Paket. Und wenn Sie Ihre eigene MCP-Infrastruktur aufbauen wollen: Wir haben es schon einmal gemacht. Wir können es auch für Sie tun.
