--- title: "Von 0 auf 260 Tools: Unsere MCP-Server Architektur" description: "58 MCP-Server, 680+ Tools, 3-Tier-Architektur. Ein Deep-Dive in die technische Infrastruktur hinter StudioMeyers AI-Plattform." author: "Matthias Meyer" published: 2026-02-26 updated: 2026-02-26 language: de tags: ["mcp", "architektur", "tools", "typescript", "infrastruktur"] canonical: "https://studiomeyer.io/de/blog/mcp-server-architektur-260-tools" markdown_versions: ["https://studiomeyer.io/de/blog/mcp-server-architektur-260-tools.md", "https://studiomeyer.io/en/blog/mcp-server-architektur-260-tools.md", "https://studiomeyer.io/es/blog/mcp-server-architektur-260-tools.md"] publisher: "StudioMeyer, https://studiomeyer.io (llms.txt: https://studiomeyer.io/llms.txt)" --- # Von 0 auf 260 Tools: Unsere MCP-Server Architektur 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 Geschäftslogik 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 Geschäftslogik, 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-Qualität, Security-Scans, Compliance-Prüfungen. ### Tier 3: Kundenfaehige Server Tier-3-Server sind so gebaut, dass sie als eigenstaendige Produkte funktionieren können. Sie haben saubere APIs, vollständige 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. ```typescript 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 verfügbar 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 überfordert. Er weiss nicht, welches Tool wann relevant ist. Die Qualität 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 zählt: Jedes Tool löst 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-Überwachung | | Deploy | 8 | 1 | Container-Management | | Outreach | 10 | 2 | E-Mail & Lead-Gen | | Onboard | 5 | 2 | Kunden-Onboarding | | Audit | Variabel | 2 | Qualität & 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: 1. **Klein starten.** Ein Server, drei Tools, ein Problem lösen. Dann erweitern. 2. **Zod-Schemas sind Pflicht.** Nicht optional, nicht "später." Vom ersten Tool an. 3. **Modular denken.** Ein Server pro Domaene, nicht ein Server für alles. 4. **Dual Transport von Anfang an.** stdio für Entwicklung, HTTP für Produktion. Beides implementieren, bevor Sie es brauchen. 5. **Factory Pattern für HTTP.** Kein geteilter State. Jede Session bekommt eine frische Instanz. Die Tools, die auf dieser Architektur laufen, finden Sie in [unserer Werkzeug-Übersicht](https://studiomeyer.io/de/developers) -- 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. ## Weiterlesen, MCP Server bauen - [MCP Server selber bauen: Schritt-für-Schritt mit TypeScript](https://studiomeyer.io/de/blog/mcp-server-selber-bauen.md) - [58 MCP-Server, 680+ Tools: Unsere KI-Infrastruktur im Detail](https://studiomeyer.io/de/blog/mcp-server-infrastruktur.md) - [MCP Server Architecture: So bauen wir intelligente Agent-Netzwerke](https://studiomeyer.io/de/blog/mcp-server-architecture.md)