Als wir bei StudioMeyer den ersten MCP Server gebaut haben, hatte er drei Tools. Heute betreiben wir 20 MCP Server mit ueber 260 Tools -- ein System, das unsere gesamte Geschaeftslogik abbildet, von CRM ueber 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 grosse System startet klein. Unser erster MCP Server war ein CRM-Tool mit drei Funktionen: Kontakt anlegen, Kontakt suchen, Kontakt aktualisieren. TypeScript, Zod-Schemas fuer 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 ueber MCP laufen." Jede Anforderung bedeutete: neue Tools, neue Schemas, neue Handler. Und hier wurde klar: Ein einzelner Server mit 260 Tools wuerde nicht funktionieren.
Die 3-Tier-Architektur
Die Loesung war eine Architektur, die Tools nach Zugriffslevel und Verantwortung trennt. Drei Ebenen, klar definiert:
Tier 1: Interne Server
Tier-1-Server sind ausschliesslich fuer unsere eigene Infrastruktur. Sie laufen lokal, kommunizieren ueber stdio (Standard Input/Output) und sind nie oeffentlich 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. Ueber 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 fuer lokale Nutzung, HTTP fuer Agent-Zugriff. Diese Server kapseln Geschaeftslogik, die von mehreren Systemen benoetigt 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 koennen. Sie haben saubere APIs, vollstaendige Dokumentation und koennen 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 fuer alles
Jedes Tool-Input wird durch ein Zod-Schema definiert. Keine any-Types, keine optionalen Validierungen. Wenn ein Parameter falsch ist, schlaegt das Schema fehl -- bevor der Handler ueberhaupt laeuft.
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 ueber stdio als auch ueber HTTP verfuegbar macht.
stdio wird verwendet, wenn der Agent den Server als Subprocess startet. Direkt, schnell, keine Netzwerk-Latenz. Ideal fuer lokale Entwicklung und Tier-1-Server.
HTTP wird verwendet, wenn Agents ueber 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 ueber ein --http Flag oder die Umgebungsvariable MCP_HTTP=1. Auf Agent-Seite wechselt MCP_TRANSPORT=http die Konfiguration automatisch.
Server Factory Pattern
Fuer HTTP-Sessions nutzen wir ein Factory Pattern: createMcpServer() erzeugt fuer jede HTTP-Session eine frische Server-Instanz. Kein geteilter State zwischen Sessions, kein Memory-Leak, keine Race Conditions.
Warum modular?
Die Versuchung ist gross, alles in einen Server zu packen. Ein Server, alle Tools, fertig. Aber das skaliert nicht -- aus mehreren Gruenden:
Toolsprawl: Ein Assistent mit 260 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 unabhaengig skaliert werden. Wenn das CRM unter Last steht, skalieren wir den CRM-Server -- nicht das gesamte System.
Die Zahlen
20 MCP Server. 260+ 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 koennen
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 "spaeter." Vom ersten Tool an.
- Modular denken. Ein Server pro Domaene, nicht ein Server fuer alles.
- Dual Transport von Anfang an. stdio fuer Entwicklung, HTTP fuer Produktion. Beides implementieren, bevor Sie es brauchen.
- Factory Pattern fuer 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 koennen es auch fuer Sie tun.
