Zum Inhalt springen
CASOON

MCP Gateway für Teams: Zentrale Verwaltung leicht gemacht

KI im Einsatz

Ab 3+ MCP Servern wird es unübersichtlich – so behältst du die Kontrolle

12 Minuten
MCP Gateway für Teams: Zentrale Verwaltung leicht gemacht
#MCP #Gateway #Enterprise #Team-Management
SerieMCP für Entwickler
Teil 3 von 8

Das Problem: Wenn MCP Server außer Kontrolle geraten

Du hast MCP Server eingerichtet, vielleicht sogar Code Execution aktiviert. Es funktioniert super.

Aber dann:

Die Probleme stapeln sich:

  1. Keine Übersicht: Wer nutzt welche MCP Server?
  2. Inkonsistente Konfiguration: Jeder hat andere Tokens, Scopes, URLs
  3. Sicherheitsrisiko: Keine zentrale Kontrolle über Zugriffsrechte
  4. Keine Audits: Wer hat wann auf was zugegriffen?
  5. Doppelte Kosten: 10 Entwickler = 10x GitHub-API-Calls statt 1x gecacht

Die Lösung: Ein MCP Gateway.

Was ist ein MCP Gateway?

Ein MCP Gateway ist ein zentraler Proxy, der zwischen deinen Entwicklern (bzw. ihren KI-Tools) und den eigentlichen MCP Servern sitzt.

Die Architektur

Ohne Gateway (jeder für sich):

1
Alice → Claude → GitHub MCP Server
2
Bob → Claude → GitHub MCP Server
3
Carol → Claude → GitHub MCP Server

3x Authentifizierung, 3x API-Calls, keine zentrale Kontrolle.

Mit Gateway (zentral verwaltet):

1
Alice / Bob / Carol Entwickler mit KI-Tools
2
MCP Gateway Authentifizierung, Caching, Policies
3
GitHub MCP Server 1x Verbindung statt 3x

1x Authentifizierung, Caching, zentrale Logs, Policy Enforcement.

Was macht ein Gateway konkret?

1. Single Sign-On für MCP Server. Statt dass jeder Entwickler eigene Tokens verwaltet, authentifiziert er sich einmal beim Gateway. Das Gateway verwaltet die Tokens zu den einzelnen MCP Servern zentral.

2. Caching. Häufige Anfragen werden gecacht. Alice fragt “Welche GitHub Issues gibt es?” – das Gateway cached das Ergebnis für 5 Minuten. Wenn Bob dieselbe Frage stellt, liefert das Gateway aus dem Cache. Kein API-Call, keine Kosten.

3. Rate Limiting. Verhindert, dass ein einzelner Entwickler die API überlastet. Zum Beispiel maximal 100 GitHub-API-Calls pro Stunde pro User, maximal 50 Sentry-API-Calls. Limits lassen sich pro Server und pro Rolle konfigurieren.

4. Access Control. Definiert, wer auf was zugreifen darf. Entwickler bekommen GitHub und Sentry read-only, der Tech Lead zusätzlich Write-Zugriff und Firebase-Admin, der PM sieht nur GitHub Issues. Eine zentrale Stelle statt verteilter Konfiguration.

5. Audit Logging. Jede Anfrage wird geloggt – wer hat wann welchen MCP Server mit welcher Operation angesprochen. Das ist nicht nur für Compliance relevant, sondern hilft auch bei der Kostenanalyse: Welcher Entwickler verbraucht die meisten API-Calls?

6. Policy Enforcement. Zentrale Regeln, die für alle gelten: Zugriff auf sensible Repos blockieren, Lösch-Operationen ohne Approval verhindern, externe Mitarbeiter auf Read-Only beschränken. Einmal definiert, überall durchgesetzt.

Wann brauche ich ein Gateway?

Du brauchst ein Gateway, wenn:

3+ MCP Server im Einsatz

  • Ab 3 Servern wird manuelle Verwaltung mühsam
  • Jeder Server hat eigene Tokens, Configs, Scopes

5+ Entwickler im Team

  • Individuelle Konfiguration ist fehleranfällig
  • Onboarding neuer Mitarbeiter dauert Stunden

Compliance-Anforderungen

  • DSGVO: “Wer hat wann auf welche Kundendaten zugegriffen?”
  • SOC 2: Audit-Logs und Access Control nötig
  • ISO 27001: Zentrale Zugriffsverwaltung Pflicht

Hohe API-Kosten

  • GitHub/Sentry/etc. kosten pro API-Call
  • Ohne Caching: Jeder Entwickler macht eigene Calls
  • Mit Gateway: Zentral gecacht → 80% weniger Calls

Externe Mitarbeiter / Freelancer

  • Contractors sollen begrenzte Zugriffsrechte haben
  • Nach Projekt-Ende: Zugriff sofort entziehen

Production-Einsatz

  • KI-Tools nicht nur für Entwickler, sondern im Produkt selbst
  • Braucht professionelle Infrastruktur

Du brauchst KEIN Gateway, wenn:

1-2 Entwickler, 1-2 MCP Server

  • Overhead lohnt sich nicht
  • Manuelle Verwaltung ist ausreichend

Nur für Experimente / Prototyping

  • Gateway-Setup kostet Zeit
  • Bei Wegwerf-Projekten unnötig

Alle MCP Server sind lokal

  • Wenn Server nur lokal laufen (localhost), ist Gateway überflüssig
  • Keine Remote-Zugriffe = keine zentrale Verwaltung nötig

Keine Compliance-Anforderungen

  • Hobby-Projekte ohne Business-Kritikalität
  • Keine sensiblen Daten

MCP Gateway Optionen: Self-Hosted vs. Managed

Es gibt zwei Ansätze: Selbst hosten oder Managed Service nutzen.

Option 1: Self-Hosted (Open Source)

Director (von Anthropic Community)

Features:

  • Zentrale MCP-Server-Verwaltung
  • User Authentication (OAuth, SAML)
  • Caching (Redis-basiert)
  • Rate Limiting
  • Audit Logs
  • Web-UI für Verwaltung

Installation (Docker):

# 1. Clone Repository
git clone https://github.com/mcp-tools/director.git
cd director

# 2. Konfiguration
cat > config.yml << 'EOF'
server:
  port: 8080
  host: 0.0.0.0

auth:
  provider: oauth
  oauth:
    issuer: https://accounts.google.com
    client_id: YOUR_CLIENT_ID
    client_secret: YOUR_CLIENT_SECRET

mcpServers:
  github:
    url: https://mcp.github.com
    auth:
      type: bearer
      token: ${GITHUB_TOKEN}
    cache:
      ttl: 300  # 5 Minuten
    rateLimit:
      requests: 100
      window: 3600  # 1 Stunde

  sentry:
    url: https://mcp.sentry.io
    auth:
      type: bearer
      token: ${SENTRY_TOKEN}
    cache:
      ttl: 60
    rateLimit:
      requests: 50
      window: 3600

accessControl:
  - role: developer
    allow:
      - github.read
      - sentry.read

  - role: admin
    allow:
      - github.*
      - sentry.*
      - firebase.*
EOF

# 3. Starte mit Docker Compose
cat > docker-compose.yml << 'EOF'
version: '3.8'

services:
  director:
    image: mcptools/director:latest
    ports:
      - "8080:8080"
    volumes:
      - ./config.yml:/app/config.yml
      - ./data:/app/data
    environment:
      GITHUB_TOKEN: ${GITHUB_TOKEN}
      SENTRY_TOKEN: ${SENTRY_TOKEN}
    depends_on:
      - redis

  redis:
    image: redis:7-alpine
    volumes:
      - redis-data:/data

volumes:
  redis-data:
EOF

# 4. Setze Environment-Variablen
export GITHUB_TOKEN="ghp_your_token"
export SENTRY_TOKEN="your_sentry_token"

# 5. Starte Services
docker-compose up -d

# 6. Check Status
curl http://localhost:8080/health
# Expected: {"status": "healthy"}

Entwickler verbinden sich:

# Statt direkt zu GitHub MCP
claude mcp add --transport http github https://mcp.github.com

# Jetzt über Gateway
claude mcp add --transport http github http://director.company.local:8080/mcp/github

Vorteile: ** Volle Kontrolle ** Open Source (kostenlos) ** On-Premise (Daten bleiben intern) ** Anpassbar

Nachteile: ** Self-Managed (du bist verantwortlich) ** Infrastruktur nötig (Server, Redis, Monitoring) ** Updates manuell

Kong Gateway mit MCP Plugin

Setup:

# 1. Kong mit Docker starten
docker run -d --name kong \
  -e "KONG_DATABASE=off" \
  -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
  -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
  -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
  -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
  -e "KONG_ADMIN_LISTEN=0.0.0.0:8001" \
  -p 8000:8000 \
  -p 8001:8001 \
  kong:latest

# 2. MCP Plugin installieren
curl -X POST http://localhost:8001/plugins \
  --data "name=mcp-proxy" \
  --data "config.cache_ttl=300" \
  --data "config.rate_limit=100"

# 3. GitHub MCP Service hinzufügen
curl -X POST http://localhost:8001/services \
  --data "name=github-mcp" \
  --data "url=https://mcp.github.com"

# 4. Route erstellen
curl -X POST http://localhost:8001/services/github-mcp/routes \
  --data "paths[]=/mcp/github"

# 5. Authentication Plugin
curl -X POST http://localhost:8001/services/github-mcp/plugins \
  --data "name=key-auth"

# 6. Rate Limiting Plugin
curl -X POST http://localhost:8001/services/github-mcp/plugins \
  --data "name=rate-limiting" \
  --data "config.minute=100"

Entwickler erhalten API-Keys:

# Admin erstellt Key für alice
curl -X POST http://localhost:8001/consumers \
  --data "username=alice"

curl -X POST http://localhost:8001/consumers/alice/key-auth \
  --data "key=alice-secret-key-abc123"

# Alice nutzt Gateway
claude mcp add --transport http github http://kong.company.local:8000/mcp/github \
  --header "apikey: alice-secret-key-abc123"

Vorteile: ** Production-Ready ** Professionelles Monitoring ** HA (High Availability) ** Support verfügbar

Nachteile: ** Komplexer Setup ** Enterprise-Features kosten Geld ** Overkill für kleine Teams

Option 2: Managed Services

Apidog MCP Gateway

Features:

  • Zero-Setup (SaaS)
  • Automatisches Caching
  • Built-in Analytics
  • Team-Management UI
  • Pay-per-Use Pricing

Setup (5 Minuten):

# 1. Registriere bei apidog.com/mcp
# 2. Erstelle Team

# 3. Füge MCP Server hinzu (Web-UI)
Team → MCP Servers → Add Server
  Name: GitHub
  URL: https://mcp.github.com
  Auth: Bearer Token
  Token: ghp_your_token
  Cache: 5 minutes
  Rate Limit: 100/hour per user

# 4. Lade Team-Mitglieder ein
Team → Members → Invite
  Email: alice@company.com (Role: Developer)
  Email: bob@company.com (Role: Developer)
  Email: admin@company.com (Role: Admin)

# 5. Entwickler erhalten automatisch Config-Link
# Klick auf Link → MCP Server automatisch in Claude konfiguriert

Entwickler-Perspektive:

1
Email-Einladung erhalten
2
"Configure Claude" Button klicken
3
Claude öffnet sich MCP Server automatisch hinzugefügt
4
Fertig

Pricing (Stand 2025):

  • Free: 1.000 API-Calls/Monat, 5 User
  • Team: 49 €/Monat, 50.000 API-Calls, unlimitierte User
  • Enterprise: Custom, SLA, On-Premise Option

Vorteile: ** Zero-Maintenance ** Schneller Setup ** Auto-Updates ** Professional Support

Nachteile: ** Kosten (ab 49 €/Monat) ** Daten gehen durch externe Infrastruktur ** Vendor Lock-in

Workato MCP Hub

Features:

  • Enterprise SSO (SAML, LDAP)
  • Advanced Workflows
  • Compliance-Ready (SOC 2, ISO 27001)
  • 24/7 Support

Pricing: Enterprise-only, Kontakt für Quote

Access Control: Wer darf was?

Ein Gateway ohne Access Control ist wie ein offenes Tor. Definiere klare Regeln.

Role-Based Access Control (RBAC)

Beispiel-Rollen:

roles:
  developer:
    description: "Normale Entwickler"
    permissions:
      - github:read
      - github:issues:write
      - sentry:read
      - puppeteer:execute
    restrictions:
      - no_delete
      - no_admin_repos

  tech-lead:
    description: "Tech Leads und Senior Developers"
    permissions:
      - github:*
      - sentry:*
      - firebase:read
      - firebase:write
    restrictions:
      - no_firebase_delete

  admin:
    description: "Admins haben volle Kontrolle"
    permissions:
      - "*"

  contractor:
    description: "Externe Mitarbeiter"
    permissions:
      - github:read
      - github:issues:write
    restrictions:
      - only_repos: ["myorg/public-project"]
      - no_sensitive_data

User Assignment:

users:
  - email: alice@company.com
    role: developer

  - email: bob@company.com
    role: tech-lead

  - email: freelancer@external.com
    role: contractor
    expires: 2025-12-31  # Zugriff endet automatisch

Feingranulare Permissions

Beispiel: GitHub MCP

github:
  alice@company.com:
    allow:
      - read:repos
      - write:issues
      - read:pull_requests
    deny:
      - delete:*
      - admin:*
    repos:
      allow: ["myorg/*"]
      deny: ["myorg/sensitive-repo"]

  bob@company.com:
    allow:
      - read:*
      - write:*
      - delete:issues  # Kann Issues löschen
    deny:
      - delete:repos  # Aber keine Repos

Beispiel: Sentry MCP

sentry:
  developer:
    allow:
      - read:issues
      - read:events
    deny:
      - write:*
      - delete:*
    projects:
      - production
      - staging

  ops-team:
    allow:
      - read:*
      - write:issues
      - resolve:issues
    projects: ["*"]

Zeit-basierte Regeln

Business Hours Only:

policies:
  - name: "Production Access nur während Arbeitszeit"
    applies_to:
      - role: developer
      - mcp_servers: ["firebase:production"]
    time:
      weekdays: true
      hours: 08:00-18:00
      timezone: Europe/Berlin
    action: deny_outside_hours

Temporary Access:

temporary_access:
  - user: contractor@external.com
    role: developer
    valid_from: 2025-10-01
    valid_until: 2025-12-31
    notify_before_expiry: 7d

Caching-Strategien

Caching ist kritisch für Performance und Kostensenkung.

Cache-TTL nach Datentyp

caching:
  github:
    list_repos:
      ttl: 3600  # 1 Stunde (ändert sich selten)

    list_issues:
      ttl: 300   # 5 Minuten (ändert sich oft)

    get_issue:
      ttl: 60    # 1 Minute (Details ändern sich häufig)

    list_commits:
      ttl: 7200  # 2 Stunden (Commits sind immutable)

  sentry:
    get_errors:
      ttl: 30    # 30 Sekunden (Errors kommen live)

    get_stats:
      ttl: 600   # 10 Minuten (Stats ändern sich langsam)

Cache Invalidation

Manuell:

# Admin kann Cache für bestimmte Operationen löschen
curl -X DELETE http://gateway/cache/github/list_issues?repo=myorg/myrepo \
  -H "Authorization: Bearer admin-token"

Automatisch bei Writes:

cache_invalidation:
  # Bei neuem Issue → invalidiere list_issues
  - trigger: github.create_issue
    invalidate:
      - github.list_issues
      - github.get_repo_stats

  # Bei Commit → invalidiere list_commits
  - trigger: github.create_commit
    invalidate:
      - github.list_commits

Shared vs. User-Specific Cache

caching:
  github.list_repos:
    type: shared  # Alle User sehen dasselbe
    ttl: 3600

  github.list_my_issues:
    type: user-specific  # Pro User gecacht
    ttl: 300

Monitoring & Alerts

Ein Gateway ohne Monitoring ist ein Blindflug.

Metriken tracken

Request Metrics:

Cache Metrics:

Cost Metrics:

Alerts konfigurieren

High Error Rate:

alerts:
  - name: "GitHub MCP High Error Rate"
    condition: |
      error_rate(github) > 0.05  # > 5% Fehler
    duration: 5m
    severity: warning
    notify:
      - slack: #ops-alerts
      - email: ops@company.com

Rate Limit Hit:

alerts:
  - name: "User hitting Rate Limit"
    condition: |
      rate_limit_exceeded(user) > 0
    severity: info
    notify:
      - slack: #dev-team
    message: |
      User {{ .user }} hit rate limit for {{ .mcp_server }}
      Current: {{ .requests }}/{{ .limit }} per hour

Slow Response:

alerts:
  - name: "MCP Server Slow"
    condition: |
      p95_duration(mcp_server) > 5s
    duration: 10m
    severity: warning
    notify:
      - pagerduty

Dashboards

Grafana Dashboard:

Audit Logging

Für Compliance und Debugging kritisch.

Was loggen?

{
  "timestamp": "2025-10-20T14:23:11.234Z",
  "request_id": "req_abc123xyz",
  "user": {
    "email": "alice@company.com",
    "role": "developer",
    "ip": "192.168.1.100"
  },
  "mcp_server": "github",
  "operation": "list_issues",
  "parameters": {
    "repo": "myorg/myrepo",
    "state": "open",
    "labels": ["bug"]
  },
  "result": {
    "status": "success",
    "items": 12,
    "cached": false,
    "duration_ms": 234
  },
  "access_control": {
    "policy_applied": "developer_read_only",
    "allowed": true
  }
}

Retention Policy

audit_logs:
  retention:
    hot_storage: 30d     # Elasticsearch: schneller Zugriff
    warm_storage: 180d   # S3: günstigerer Storage
    cold_storage: 2y     # Glacier: Compliance

  after_retention:
    action: delete       # oder: archive_to_tape

Audit Queries

Häufige Fragen:

-- Wer hat auf sensible Repos zugegriffen?
SELECT user, operation, timestamp
FROM audit_logs
WHERE mcp_server = 'github'
  AND repo LIKE 'myorg/sensitive-%'
  AND timestamp > NOW() - INTERVAL '30 days'

-- Welche Operationen wurden denied?
SELECT user, operation, reason, COUNT(*)
FROM audit_logs
WHERE access_control.allowed = false
GROUP BY user, operation, reason
ORDER BY COUNT(*) DESC

-- Top API-Call-Verbraucher
SELECT user, COUNT(*) as requests, SUM(result.items) as items_returned
FROM audit_logs
WHERE timestamp > NOW() - INTERVAL '7 days'
  AND result.cached = false
GROUP BY user
ORDER BY requests DESC
LIMIT 10

Best Practices

1. Start Small, Scale Later

1
Phase 1 (1-5 User) Kein Gateway – Manuelle Konfiguration ist okay
2
Phase 2 (5-15 User) Simple Gateway (Director) – Basic Caching, Simple RBAC
3
Phase 3 (15-50 User) Kong oder Managed Service – Advanced Caching, Granulare Permissions, Monitoring
4
Phase 4 (50+ User) Enterprise Setup – HA, Multi-Region, Advanced Compliance

2. Security First

security_checklist:
  - [ ] HTTPS nur (kein HTTP)
  - [ ] Token-Rotation (90 Tage)
  - [ ] Least-Privilege (minimale Rechte)
  - [ ] Audit-Logs aktiviert
  - [ ] Alerts für anomale Nutzung
  - [ ] Regelmäßige Access-Reviews
  - [ ] Offboarding-Prozess (Zugriff entziehen)

3. Documentation for Team

# MCP Gateway - Team Guide

## Zugriff erhalten
1. Frage Admin um Zugang
2. Du erhältst Email mit Gateway-URL
3. Konfiguriere Claude: `claude mcp add ...`

## Welche MCP Server gibt es?
- GitHub: Code, Issues, PRs
- Sentry: Error Tracking
- Firebase: Datenbank

## Limits
- GitHub: 100 Calls/Stunde
- Sentry: 50 Calls/Stunde

## Bei Problemen
- Check Status: https://gateway.company.local/status
- Slack: #mcp-support

4. Cost Monitoring

cost_tracking:
  - provider: github
    cost_per_api_call: 0.001 €
    monthly_budget: 100 €
    alert_at: 80%

  - provider: sentry
    cost_per_api_call: 0.002 €
    monthly_budget: 50 €
    alert_at: 80%

Zusammenfassung: Die 5 wichtigsten Erkenntnisse

1. Gateway ab 3+ MCP Servern sinnvoll Darunter ist manuelle Verwaltung ausreichend. Darüber wird es chaotisch ohne zentrale Steuerung.

2. Self-Hosted vs. Managed Director (Open Source) für volle Kontrolle, Apidog/Workato für Zero-Maintenance. Kong für Enterprise-Grade Features.

3. Access Control ist kritisch RBAC, feingranulare Permissions, Zeit-basierte Regeln – sonst ist Gateway ein Sicherheitsrisiko statt Lösung.

4. Caching spart 50-80% Kosten Richtig konfiguriert, reduziert Caching API-Calls drastisch. TTL nach Datentyp optimieren.

5. Monitoring & Audits für Compliance Ohne Logs und Metrics ist Gateway ein Blackbox. Für DSGVO/SOC 2 sind Audits Pflicht.

Nächste Schritte

Jetzt starten:

# Für kleine Teams (5-15 User)
git clone https://github.com/mcp-tools/director.git
cd director
docker-compose up -d

# Für größere Teams (15+)
→ Evaluiere Apidog oder Kong

Viel Erfolg!