MCP-Server + AWS Bedrock: Wie Engineering-Teams interne KI-Workflows mit AI-Coding-Tools verbinden

MCP-Server als Brücke zwischen AWS-Bedrock-Workflows und AI-Coding-Tools: Dokumenten-KI und RAG-Assistenten direkt im Engineering-Workflow.

Veröffentlicht: 2026-05-30. Aktualisiert: 2026-05-30.

Das Wichtigste in Kürze

  • MCP-Server können nicht nur Jira oder GitLab anbinden - auch eure produktiven AWS-Bedrock-Workloads sind über MCP zugänglich.
  • Cross-Sell-Pattern: Wer schon Dokumenten-KI oder RAG mit Bedrock betreibt, gewinnt mit MCP einen Engineer-Productivity-Layer obendrauf.
  • Bedrock-Knowledge-Bases als MCP-Resource: euer interner Assistent wird in Claude Code, Codex und Cursor abfragbar.
  • Permission-Modell ist kritisch: Bedrock-Agents haben oft Production-Schreibrechte - die wollen explizit konfiguriert sein.
  • AWS-eu-central-1-Pattern bleibt DSGVO-konform, auch wenn AI-Coding-Tools eingesetzt werden - solange das LLM in eu-central-1 bleibt.

Wer schon AWS-Bedrock-Workloads betreibt (Dokumenten-Verarbeitung, RAG-Assistenten, Agent-Workflows), kann sie über einen MCP-Server direkt aus Claude Code, Codex oder Cursor nutzen. Statt UI-Switches und Copy-Paste laufen die Bedrock-Aufrufe als normale Tool-Calls im Coding-Workflow. Architektur-Pattern, Implementation, Use-Cases.

Das Problem: Zwei AI-Welten ohne Brücke

Stellt euch einen typischen Mittelstand-Stack 2026 vor:

  • AWS-Bedrock-basierte KI-Workloads für Dokumenten-Verarbeitung (Rechnungen extrahieren), RAG-Assistenten (internes Wissen abfragen), Agent-Workflows (Angebote generieren). DSGVO-konform in eu-central-1.
  • Engineering-Team nutzt Claude Code, Cursor und Codex für tägliche Entwicklungsarbeit.

Beide Welten sind getrennt. Engineers können nicht direkt aus ihrem AI-Coding-Tool auf die internen Bedrock-Workloads zugreifen. Wer den internen RAG-Assistenten zur Architektur-Frage konsultieren will, muss separate UI öffnen, Query eingeben, Antwort kopieren, zurück in IDE - Reibung pro Task.

Resultat: Die internen KI-Workloads werden unter ihrem Potenzial genutzt. Sie helfen Business-Usern, aber nicht den Engineers, die sie gebaut haben.

Die Lösung: MCP-Server als Bridge

Ein MCP-Server vor euren Bedrock-Workloads schließt die Lücke:

┌─────────────────┐         ┌──────────────────┐
│ AI Coding Tools │         │  AWS eu-central-1 │
│ (Claude Code,   │  MCP    │                   │
│  Cursor, Codex) │ ──────► │  MCP-Server      │
│                 │         │      │            │
└─────────────────┘         │      ▼            │
                            │  Bedrock-Workloads│
                            │  - Dokumenten-KI  │
                            │  - RAG-KB         │
                            │  - Agents         │
                            └──────────────────┘

Engineers können direkt im Coding-Tool:

  • Eine Frage an den internen RAG-Assistenten stellen
  • Ein Dokument durch die Bedrock-Extraktions-Pipeline schicken
  • Einen Bedrock-Agent für eine spezifische Aufgabe triggern

Die Antworten kommen strukturiert zurück und können direkt in Code, Doku oder PR-Beschreibung verwendet werden.

Use-Cases: Was Engineers damit machen

Use-Case 1: Architektur-Frage an internen RAG-Assistenten

Engineer schreibt eine neue Komponente und ist unsicher über die existierende Pattern-Library. Statt Slack-Suche oder Confluence-Walking:

> Frag mein-rag-mcp: "Welches Pattern nutzen wir für Form-Validation in React?"

# Antwort kommt mit Quellenverweis auf interne ADR-Doku.

Use-Case 2: Dokumenten-Extraktion im Test-Setup

Engineer baut Tests für die Rechnungs-Pipeline. Statt manueller Test-Daten:

> Trigger bedrock-doc-extraction für ./testdata/sample-invoice.pdf

# Bekommt JSON-Output direkt zurück, kopiert in Test-Fixture.

Use-Case 3: PR-Review mit Domain-Kontext

Vor PR-Review fragt der Engineer den Code-Review-Workflow:

> /review mit Domain-Kontext aus bedrock-knowledge-base "compliance-rules"

# Review enthält automatisch Hinweise auf domain-spezifische Regeln.

In allen drei Fällen: keine UI-Switching, keine Copy-Paste, keine Reibung.

Architektur-Pattern im Detail

So sieht ein produktiver MCP-Bedrock-Setup aus:

MCP-Server-Komponente (TypeScript oder Python):

  • Läuft als Container in eurem AWS-Account (ECS Fargate oder Lambda)
  • HTTP-Endpoint mit MCP-Protocol über HTTPS
  • Authentifizierung pro Tool-Gruppe (Bedrock-Read, Bedrock-Invoke, KB-Query)
  • Strukturierte Logs pro Invocation an CloudWatch oder SIEM

Bedrock-Tools im MCP-Server:

// Beispiel: bedrock-rag-query Tool
export const bedrockRagQuery: Tool = {
  name: "bedrock_rag_query",
  description: "Query the internal knowledge base via Bedrock RAG",
  inputSchema: z.object({
    query: z.string().min(3).max(500),
    knowledgeBaseId: z.string(),
  }),
  async handler(input, context) {
    await checkPermission(context, "bedrock:rag:query");
    const result = await bedrockClient.retrieveAndGenerate({
      input: { text: input.query },
      retrieveAndGenerateConfiguration: {
        type: "KNOWLEDGE_BASE",
        knowledgeBaseConfiguration: {
          knowledgeBaseId: input.knowledgeBaseId,
          modelArn: "anthropic.claude-sonnet-4-6-v1:0",
        },
      },
    });
    return {
      content: [
        { type: "text", text: result.output.text },
        { type: "text", text: `Sources: ${JSON.stringify(result.citations)}` },
      ],
    };
  },
};

Bedrock-Workloads bleiben unverändert:

  • Dokumenten-KI-Pipeline (Textract + Bedrock-Klassifikation)
  • RAG-Knowledge-Bases (S3-basierte Vector-DB + Bedrock-Retrieval)
  • Bedrock-Agents (für mehrstufige Workflows)

Der MCP-Server ist die Schnittstelle, nicht die Workload selbst. Eure existierenden Bedrock-Investitionen bleiben.

Permission-Modell: das ist nicht optional

Bedrock-Workloads haben oft sensitive Daten und Schreibrechte auf Production-Systeme. Das Permission-Modell ist nicht optional:

  1. Read-Only-Default. Die meisten Engineer-Use-Cases brauchen Read-Access (RAG-Query, Doku-Extraction). Schreibende Tools (Agent-Triggers, KB-Inserts) brauchen explizite Berechtigung.

  2. Tool-Group-Tokens. Statt eines Master-Tokens: separate Tokens für Read, Invoke, Admin. Engineers haben Read+Invoke. Platform-Engineers haben Admin.

  3. Audit-Logs. Jeder MCP-Tool-Call landet als strukturierter Log in CloudWatch (oder eurem SIEM). Compliance kann genau nachvollziehen, was über AI-Coding-Tools an Bedrock geschickt wurde.

Ohne diese drei Schichten ist das Setup kein Production-Pattern, sondern eine Sicherheitslücke.

DSGVO + Datenresidency: was bleibt im EU-Raum

Ein häufiges Missverständnis: „Wenn ich Claude Code nutze, gehen meine Daten nach USA." Das stimmt für die LLM-Anfrage (Sonnet-Antwort kommt von Anthropic-Servern), aber:

  • Eure Daten in Bedrock-Workloads bleiben in eu-central-1.
  • Der MCP-Server läuft in eu-central-1.
  • Der Engineer-Prompt geht an Anthropic (USA oder EU je nach Vertrag).
  • Die strukturierte Antwort vom MCP-Server zurück enthält Bedrock-Output - der bleibt in eu-central-1 erzeugt, geht aber als String an den Engineer (und damit potentiell durch die LLM-Pipeline).

Wer maximale Datenresidency will: Anthropic Bedrock-Modelle in eu-central-1 nutzen (Claude über Bedrock statt über Anthropic-API direkt). Dann ist der gesamte Roundtrip in EU.

Mehr dazu im Service DSGVO-konforme KI-Integration - der MCP-Bedrock-Bridge-Setup baut auf diese Foundation auf.

Implementierungs-Schritte

Realistischer Zeitplan für ein typisches Mittelstand-Setup mit 2 Bedrock-Workloads:

Woche 1: Discovery + Tool-Design

  • Mapping: welche Bedrock-Workloads gibt es, welche sollen via MCP zugänglich sein
  • Permission-Modell entwerfen (Read/Invoke/Admin pro Tool-Gruppe)
  • Auth-Strategie (Token-Provisioning, Rotation)

Woche 2-3: Implementation

  • MCP-Server-Skeleton in TypeScript
  • 2-4 Tools für die Bedrock-Workloads (z.B. doc-extract, rag-query, agent-trigger)
  • 1-2 Resources für statische Konfiguration (z.B. KB-Catalog)
  • Unit + Integration-Tests
  • CI-Pipeline (GitHub Actions oder GitLab CI)

Woche 4: Deployment + Team-Übergabe

  • Docker-Container in ECR, Deploy via Fargate
  • Engineer-Setup-Doku: wie verbindet man Claude Code mit dem MCP-Server
  • Team-Session mit Live-Demo
  • Audit-Log-Dashboard für Compliance

Pro zusätzlichem Bedrock-Workload danach: ~3-5 Tage.

Was ihr damit nicht macht

Drei explizite Anti-Patterns:

  • Production-Schreibrechte für jeden Engineer. MCP-Tools mit Schreibzugriff auf Production-Datenbanken oder Agents mit autonomen Side-Effects: nein. Schreibend nur für Platform-Engineers oder mit Approval-Flow.
  • Auth-Token im Repo. Niemals. Tokens via AWS Secrets Manager + Rotation, niemals committet.
  • Bedrock-Costs out of Sight. AI-Coding-Tools können viele Bedrock-Calls triggern. Cost-Alarms auf Bedrock-Spend einrichten, sonst überrascht die monatliche Rechnung.

Wer profitiert besonders?

Drei Profile, für die der MCP-Bedrock-Bridge-Setup besonders sinnvoll ist:

  • Mittelständische Unternehmen, die schon Bedrock-Workloads betreiben. Geringer Setup-Aufwand, hoher Engineer-Productivity-Hebel.
  • Engineering-Teams mit Compliance-Anforderungen. Datenresidency und Audit-Trail sind eingebaut, nicht nachträglich gefrickelt.
  • Platform-Teams in größeren Organisationen. Einmal aufgebaut, profitieren alle Service-Teams. Skaliert besser als jedes Team-eigene Setup.

Nächste Schritte

Wer schon Bedrock-Workloads hat und den MCP-Bridge-Setup pilotieren will: das ist die Schnittstelle meiner Services MCP-Server Custom-Development und Dokumenten-KI & Automatisierung. Ein erster Pilot mit einem Bedrock-Workload als MCP-Tool ist ein 2-3-Wochen-Projekt.

Wer noch keine Bedrock-Workloads betreibt, aber AI-Coding-Tools nutzt, sollte zuerst den Entwicklungsworkflow stabilisieren. Die Produkt-Discovery ist dafür der begrenzte Einstieg. Die Bedrock-Integration folgt, wenn der Workflow im Team funktioniert.

Verwandte Posts: MCP-Server entwickeln, Bedrock AgentCore + OpenClaw.

Häufige Fragen

Was bringt es, MCP-Server vor Bedrock-Workloads zu setzen?

MCP macht eure Bedrock-basierten KI-Services (Dokumenten-Verarbeitung, RAG-Assistenten, Agent-Workflows) direkt in AI-Coding-Tools nutzbar. Engineers können während des Codens auf eure internen KI-Assistenten zugreifen, ohne separate UI oder Workflow-Wechsel.

Verlangsamt der MCP-Layer Bedrock-Calls?

Bei strukturierter Implementation: <50ms Overhead pro Call. Der MCP-Server fügt nur Routing + Auth + Logging hinzu. Latenz dominiert durch Bedrock selbst (typisch 500-2000ms je nach Modell und Tokens). Der MCP-Layer ist nicht der Bottleneck.

Wie bleibt das DSGVO-konform?

Bedrock läuft in eu-central-1 (Frankfurt), kein Datentransfer in Drittländer. MCP-Server läuft im selben AWS-Account oder VPC. AI-Coding-Tools senden nur die Query (nicht die Daten) an die LLM-API - die Daten bleiben innerhalb eurer AWS-Region. ZDR-konfigurierte Setups sind Standard.

Wer sollte diesen Setup wählen?

Unternehmen, die schon Bedrock-Workloads betreiben (Dokumenten-KI, RAG, Agents) und parallel Engineering-Teams haben, die AI-Coding-Tools nutzen. Der Setup verbindet beide Welten und schafft messbare Produktivitätsgewinne ohne Duplikation.

Wie aufwändig ist die Implementation?

Pro Bedrock-Workload als MCP-Tool: ~3-5 Engineer-Tage. Pro Bedrock-Knowledge-Base als MCP-Resource: ~2 Tage. Gesamt-Setup für einen typischen Mittelstand-Stack (2 Workloads + 1 Knowledge-Base + Auth + CI): 2-3 Wochen.