MCP Gateway für Teams: Zentrale Verwaltung leicht gemacht

Das Problem: Wenn MCP Server außer Kontrolle geraten

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

Aber dann:

Entwickler A: "Ich habe GitHub, Sentry und Puppeteer konfiguriert"
Entwickler B: "Ich nutze GitLab, Jira und Firebase"
Entwickler C: "Ich habe noch einen Custom MCP für unsere API gebaut"
PM: "Moment... welche MCP Server nutzen wir jetzt eigentlich?"

Die Probleme stapeln sich:

Keine Übersicht: Wer nutzt welche MCP Server?
Inkonsistente Konfiguration: Jeder hat andere Tokens, Scopes, URLs
Sicherheitsrisiko: Keine zentrale Kontrolle über Zugriffsrechte
Keine Audits: Wer hat wann auf was zugegriffen?
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):

Alice → Claude → GitHub MCP Server
Bob   → Claude → GitHub MCP Server
Carol → Claude → GitHub MCP Server

Problem: 3x Authentifizierung, 3x API-Calls, keine zentrale Kontrolle

Mit Gateway (zentral verwaltet):

Alice → Claude ↘
Bob   → Claude → MCP Gateway → GitHub MCP Server
Carol → Claude ↗

Vorteil: 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:

Entwickler authentifiziert sich beim Gateway
Gateway verwaltet die MCP-Server-Tokens zentral

2. Caching

Häufige Anfragen werden gecacht:

Alice fragt: "Welche GitHub Issues gibt es?"
→ Gateway cached das Ergebnis für 5 Minuten

Bob fragt: "Welche GitHub Issues gibt es?"
→ Gateway liefert aus Cache (keine API-Call, keine Kosten)

3. Rate Limiting

Verhindert, dass ein Entwickler die API überlastet:

Max 100 GitHub-API-Calls pro Stunde pro User
Max 50 Sentry-API-Calls pro Stunde pro User

4. Access Control

Definiere, wer auf was zugreifen darf:

Entwickler: GitHub read, Sentry read
Tech Lead: GitHub write, Sentry write, Firebase admin
PM: GitHub issues read-only

5. Audit Logging

Jede Anfrage wird geloggt:

2025-10-20 14:23:11 | [email protected] | github.listIssues | repo=myorg/myrepo
2025-10-20 14:23:45 | [email protected] | sentry.getErrors | project=production

6. Policy Enforcement

Zentrale Regeln für alle:

** Blockiere Zugriff auf sensible Repos
** Blockiere Lösch-Operationen ohne Approval
** Erlaube Read-Only für externe Mitarbeiter

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)

Was ist Director?

Ein Open-Source MCP Gateway, speziell für Teams entwickelt¹.

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

Was ist Kong?

Ein etabliertes API-Gateway, das ein MCP-Plugin hat².

Warum Kong?

Enterprise-Grade Features (HA, Monitoring, Metrics)
Riesiges Plugin-Ökosystem
Professioneller Support verfügbar

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

Was ist Apidog?

Ein Managed MCP Gateway speziell für Teams³.

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: [email protected] (Role: Developer)
  Email: [email protected] (Role: Developer)
  Email: [email protected] (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

Was ist Workato?

Enterprise-Integration-Plattform mit MCP-Support⁴.

Wann nutzen?

Großes Unternehmen (100+ User)
Bereits Workato-Kunde
Komplexe Integration-Szenarien (z.B. MCP + Salesforce + SAP)

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: [email protected]
    role: developer

  - email: [email protected]
    role: tech-lead

  - email: [email protected]
    role: contractor
    expires: 2025-12-31  # Zugriff endet automatisch

Feingranulare Permissions

Beispiel: GitHub MCP

github:
  [email protected]:
    allow:
      - read:repos
      - write:issues
      - read:pull_requests
    deny:
      - delete:*
      - admin:*
    repos:
      allow: ["myorg/*"]
      deny: ["myorg/sensitive-repo"]

  [email protected]:
    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: [email protected]
    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:

mcp_gateway_requests_total{mcp_server="github", method="list_issues", status="success"} 1247
mcp_gateway_requests_total{mcp_server="sentry", method="get_errors", status="error"} 3

mcp_gateway_request_duration_seconds{mcp_server="github"} 0.234
mcp_gateway_request_duration_seconds{mcp_server="sentry"} 1.456

Cache Metrics:

mcp_gateway_cache_hits_total{mcp_server="github"} 892
mcp_gateway_cache_misses_total{mcp_server="github"} 108

Cache Hit Rate: 89.2%

Cost Metrics:

mcp_gateway_api_calls_total{mcp_server="github"} 234
mcp_gateway_api_calls_saved{mcp_server="github"} 1013

Saved API Calls: 1013 (81% reduction)

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: [email protected]

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:

Panel 1: Request Rate (Requests/Second)
  - Pro MCP Server
  - Pro User
  - Success vs. Error

Panel 2: Latency (P50, P95, P99)
  - Pro MCP Server
  - Trend über Zeit

Panel 3: Cache Performance
  - Hit Rate
  - Saved API Calls
  - Cost Savings

Panel 4: Top Users
  - Requests/User
  - Errors/User
  - Cache Hit Rate/User

Panel 5: Access Control
  - Denied Requests
  - Policy Violations
  - Expired Tokens

Audit Logging

Für Compliance und Debugging kritisch.

Was loggen?

{
  "timestamp": "2025-10-20T14:23:11.234Z",
  "request_id": "req_abc123xyz",
  "user": {
    "email": "[email protected]",
    "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

Phase 1 (1-5 User): Kein Gateway
  - Manuelle Konfiguration ist okay

Phase 2 (5-15 User): Simple Gateway (Director)
  - Basic Caching
  - Simple RBAC

Phase 3 (15-50 User): Kong oder Managed Service
  - Advanced Caching
  - Granulare Permissions
  - Monitoring

Phase 4 (50+ User): Enterprise Setup
  - HA (High Availability)
  - 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!

Insights