MCP-Hosting-Pipeline auf AWS

Vision

Wiederverwendbare Pipeline „Spec → Hosted MCP auf AWS” — am gsuite-Beispiel gebaut, parallel als Pattern extrahiert. Endzustand: Marvin sagt „Bau MCP für Software X”, schrittweise Pipeline läuft mit Decision-Points, 2-3 Tage später ist hosted MCP auf AWS produktiv.

Stack-Entscheidungen (final, NICHT mehr diskutieren)

Was schon existiert (NICHT doppelt bauen)

• mcp-vf-hosted — ~/source/mcps/mcp-vf-hosted/ — Template-Basis. Kopieren, Sub-MCP-Liste tauschen
• mcp-gsuite — ~/source/mcps/mcp-gsuite/ — der Sub-MCP der gehosted wird (Marvin’s Fork mit Bulk/Unsubscribe/YouTube)
• mcp-eigenbau — Skill für lokalen Sub-MCP-Bau
• mcp-cloud-bereitstellung — Skill für Mono-MCP-Hosting auf Railway (wird Phase 4 um AWS-Variante erweitert)
• _index — AWS Org + Accounts dokumentiert
• OAuth-Tokens lokal: ~/.config/mcp-gsuite/.oauth2.{hello,marvinkuehlmann}@*.json
• Anthropic-Skill mcp-builder (Plugin-Cache) — Tool-Design-Patterns als Referenz
• Compound-Engineering-Skill agent-native-architecture — Design-Prinzipien (Tools = Primitives, CRUD-Vollständigkeit)

Phasen + Steps mit Status

Phase 1A: gsuite Single-User auf AWS (für Marvin allein, Pattern-Etablierung)

Ziel: gsuite-MCP läuft hosted in av-production, Marvin erreicht ihn von claude.ai Pro / iPhone. Erstanwendung des ECS-Express-Patterns — Lessons-Learned wandern in mcp-hosting-aws-ecs-express.

Wall-Clock: 1-2 Tage (bottleneck: Marvin-Reviews + DNS/TLS-Wartezeiten)

Phase 1B: VF-Migration auf AWS (papierkram + ticketpay, M365 deferred)

Ziel: Bestehender Mono-MCP mcp-vf-hosted (heute auf Railway, mcp-vf-hosted) wandert nach av-production. Cloudflare-Origin schaltet von Railway auf AWS um, Domain mcp-vf.agenticventures.de bleibt, claude.ai-Connector bei André unverändert. Railway-Instanz bleibt 1-2 Wochen parallel als Rollback-Sicherung. M365 ist bewusst draussen bis Compliance-Review (Mail-Zugriff, Drive-Files, Tenant-Isolation, AVV-Klauseln) abgeschlossen ist — Code im Repo auskommentiert, Re-Enable ist 6-Stellen-Patch.

Aktueller Stand 2026-05-11 (Architektur-Pivot durchgezogen): ECS-Express-Cutover-Versuch gescheitert wegen Custom-Domain-Issue (AWS-managed ALB akzeptiert nur eigenen Hostname → 404). Plus: ECS Express unterstuetzt nur 1 primary Container, kein Cloudflare-Tunnel-Sidecar moeglich. Pivot auf klassisches ECS Fargate + Cloudflare-Tunnel-Sidecar erfolgreich deployed (1B.8 ✅). Pattern-File: mcp-hosting-fargate-tunnel. Decision: hosted-mcp-architektur-2026. Tunnel ce6dd7c0-d31c-456c-be8a-8705c079982d mit 4 Connections nach Frankfurt registered. M365 ist wieder aktiv im Stack (3 Sub-MCPs proxied — papierkram + ticketpay + m365). Production-Risiko bleibt 0 — Andre nutzt noch nicht aktiv. Naechster Schritt: 1B.9 DNS-Cutover.

Repo-Stand seit 2026-05-10 (lokal, AWS-Deploy gebuendelt mit Cloudflare-Cutover): Drei Workflow-Prompts in prompts.py registriert (/offene_posten, /event_bilanz(event_id), /monatsabschluss(monat)) — André bekommt Slash-Commands die Sub-MCP-Tools choreografieren. /health erweitert auf Diagnostic-JSON (version + submcps_active + uptime). Test-Suite 27/27 grün (5 neue für Prompts, 3 neue fuer Health). Container lokal gebaut + gesmoked. ECR-Push + ECS-Force-Deploy faellt zusammen mit Cloudflare-Cutover an, damit nur ein Deploy-Event statt zwei.

Wall-Clock: 1-2 Tage aktiv + 1-2 Wochen Parallel-Lauf bevor Railway abgeschaltet wird

Compliance-Folge-Schritt (separat, nicht hier): M365 Re-Enable — eigenes Mini-Projekt mit AVV-Klauseln, Tenant-Isolation-Test, Audit-Plan. Kommt nach VF-Migration stabil + Compliance-Review-OK.

Phase 2: Multi-Tenant-Architektur (DynamoDB Operational + S3-Vault Knowledge)

Ziel: Multi-Tenant-Foundation des Produkt-Bundles (produkt-bundle). Pro Kunde: eigener Vault (S3) fuer Knowledge + eigene DynamoDB-Items fuer Operational, beide KMS-encrypted und ABAC-isoliert. Andre (oder beliebiger User) klickt „Connect Gmail” → autorisiert mit seinem Gmail → sieht seine Mails. Strikte User-Isolation. Architektur: markdown-und-db-trennung.

Wall-Clock: 2-3 Tage (bottleneck: Andre-Test koordinieren)

Phase 3: Production-Ready für externe Nutzer (Composio-Hybrid)

Wall-Clock: 1-2 Wochen aktiv + AVV-Wartezeiten

Phase 4: Pipeline als Skills (parallel zu Phase 2/3)

Wall-Clock: 2-3 Tage (parallel)

Decision-Points (wo Marvin im Loop bleibt)

Was Claude (Agent) NICHT kann

• AWS Console-Klicks (nur via CLI)
• OAuth-Browser-Consent-Flow durchklicken
• DNS-Records in Strato setzen
• claude.ai Custom-Connector einrichten (Marvins Account)
• Composio/Scalekit Production-Account anlegen
• Echte User-Tests mit Andre koordinieren

→ Bei diesen Punkten stoppt Claude und gibt Marvin konkrete Anleitung mit Deep-Links.

Risiken & Mitigationen

Cross-Refs

• produkt-bundle — uebergeordnetes Produkt das diese Pipeline ausfuehrt. Phase 1-4 hier sind technische Bausteine fuer Phasen A/B/C dort.
• markdown-und-db-trennung — erweitert Phase 2 um S3-Vault zusaetzlich zu DynamoDB (~+1 Woche)
• service-first-zu-produkt — Sequenzierung Service → Produkt
• mcp-hosting-aws-ecs-express — destilliertes Pattern (Architektur, IAM, Cost-Modell, Lessons-Learned). Ab Phase 1.2 fortlaufend gepflegt.
• _index — AWS-Account-Inventar + Bedrock-Status
• accounts — Account-IDs + CLI-Profile
• mcp-vf-hosted — Template-Basis
• mcp-gsuite — Sub-MCP-Source
• mcp-vf-hosted — Hosting-Pattern (Railway-Variante als Referenz)
• mcp-eigenbau — Lokal-Bau Skill
• mcp-cloud-bereitstellung — Cloud-Deploy Skill (wird Phase 4 erweitert)
• Memory: MCP-as-a-Service Vision, AWS-First Hosting

Verlauf

• 2026-05-09: Projekt angelegt. Plan finalisiert nach Recherche (App Runner ist tot → ECS Express Mode; Restricted-Scope-Verification ist 5-15k$/Jahr → Composio-Hybrid für Phase 3). Stack-Entscheidungen final.
• 2026-05-10 (Hebel 2/3/4 — UX/Diagnostic-Polish): Drei Workflow-Prompts (offene_posten, event_bilanz, monatsabschluss) in mcp-vf-hosted/src/mcp_vf_hosted/prompts.py via @mcp.prompt-Decorator registriert. Erweiterter /health mit version/submcps_active/uptime_seconds. Sub-MCP-Tool-Descriptions geprueft — schon deutsch und prägnant, keine Aktion noetig (= Hebel 3 stiller Skip). Tests +8 (27/27 grün). Container lokal gesmoked. AWS-Deploy mit Cloudflare-Cutover gebuendelt.
• 2026-05-11 (Fargate-Tunnel-Pivot 1B.8 durchgezogen): Alter McpVfHosted-Stack abgerissen (vorher DeletionPolicy Delete→Retain auf mcp-vf-hosted/upstream-tokens gepatcht via update-stack — sonst waeren die 6 Sub-MCP-Tokens beim Delete weg gewesen). Neuer Stack komplett umgeschrieben (mcp-vf-hosted-stack.ts.ecs-express-backup als Backup behalten): FargateService + FargateTaskDefinition mit 2 Containern (vf-mono + cloudflared/cloudflared:latest-Sidecar), egress-only SG, kein ALB, Cluster default und Default-VPC importiert. 3 Versuche bis CREATE_COMPLETE: (1) fromSecretNameV2 generiert Wildcard-ARN -?????? in IAM-Policy, aber ECS ValueFrom ruft Name-only-ARN → AccessDenied. Fix: fromSecretCompleteArn mit echtem ARN inkl. -AHEi6G/-q5MEkS. (2) Health-Check curl -f localhost:8080/health schlaegt fehl weil python:3.12-slim kein curl hat. Fix: python -c "import urllib.request,sys; sys.exit(0 if urllib.request.urlopen(\"http://localhost:8080/health\", timeout=3).status==200 else 1)". (3) Deploy CREATE_COMPLETE in 149s, Service ACTIVE 1/1/0, Tunnel registered (4 QUIC-Connections nach fra16/03/20/08), interner Health-Check alle 30s 200. M365 wieder aktiv mitsamt papierkram + ticketpay — alle 3 Sub-MCPs proxied. Offen: 1B.9 DNS-Cutover — Marvin muss CNAME mcp-vf in CF auf ce6dd7c0...cfargotunnel.com aendern (UI oder API mit CF_API_TOKEN/CF_ZONE_ID).
• 2026-05-10: Phase 1 in 1A (gsuite, Pattern-Etablierung, 1A.1-1A.3 ✅) und 1B (VF-Migration, papierkram + ticketpay, M365 deferred) gesplittet. 1B.1 ✅ — mcp-vf-hosted repo getrimmt: M365-Dependency + Code-Pfade in-place auskommentiert mit konsistentem Re-Enable-Marker, boto3 für Bootstrap-Optionalität dazu, .dockerignore neu gegen .env-Leak, README auf AWS-ECS-Express umgeschrieben, 19/19 Tests grün. 1B.2 ✅ — CDK-Stack infra/ analog gsuite-hosted angelegt, Sub-MCP-Tokens via ECS-secrets:-Mapping (<arn>:KEY::-Syntax) statt File-Bootstrap (kein entrypoint.sh nötig). cdk diff grün gegen av-production: 7 Resources + 1 IAM-Policy, Trust-Principals korrekt (ExecRole/TaskRole = ecs-tasks, InfraRole = ecs.amazonaws.com). 1B.3 ✅ — docker buildx build --platform linux/amd64 durch (430 MB Build-Context, Sub-MCP-venvs ziehen mit — Tweak vor Push siehe Status). Container startet, beide Sub-MCP-Subprozesse submcp_proxied (papierkram + ticketpay, kein m365), /health → 200 {"ok":true}. Architektur-Doc neu unter ~/source/mcps/mcp-vf-hosted/docs/architecture.md mit Mermaid-Diagrammen für Trust-Boundaries, Sub-MCP-Komposition und Tool-Call-Sequenz. 1B.4 ✅ — Production-Tokens via railway variables --service vf-mcp --kv lokal gezogen, 3 Sub-MCP-Tokens (PAPIERKRAM_TOKEN/SUBDOMAIN, TICKETPAY_API_KEY) als JSON ins Secrets Manager mcp-vf-hosted/upstream-tokens gepusht (Python-Pipe, nie in Bash-Stdout). 2 Scalekit-Werte hardcoded im Stack (nicht-secret). cdk deploy brauchte 3 Anläufe (5 Lessons-Learned ins Pattern-File geschrieben): IAM-Description darf nur ASCII enthalten (Em-Dash failed), CPU/Memory braucht Fargate-MiB-Format '1024'/'2048' nicht '1'/'2', retained ECR-Repo nach Failed-Stack-Rollback via Repository.fromRepositoryName umgehen. Stack CREATE_COMPLETE nach 380s, ServiceEndpoint mc-1a56ed08537b4f9fae11028fe698af47.ecs.eu-central-1.on.aws, /health HTTP 200 {"ok":true} mit Security-Headern. Railway-Token-File geshredded.