Agenten, die wirklich etwas tun — über MCP an Ihre Systeme angebunden

Was ist das Model Context Protocol (MCP)?

Solange ein Sprachmodell nur antworten kann, bleibt es ein gut formulierter Berater ohne Hände. Erst wenn es Werkzeuge aufrufen, Ressourcen lesen und Aktionen anstoßen kann, wird daraus ein Agent. Das Model Context Protocol — Ende 2024 von Anthropic als offener Standard veröffentlicht — beschreibt, wie genau diese Verbindung zwischen Modell und Außenwelt aussieht.

Vor MCP hat jede Plattform ihr eigenes Werkzeug-Format gepflegt: OpenAI-Function-Calls, Anthropic-Tools, ein Dutzend proprietärer SDKs, dazwischen halb dokumentierte Webhooks. Wer einen Kalender-Connector gebaut hatte, durfte ihn für die nächste Plattform neu schreiben. MCP ersetzt diese Wildwuchs-Kopplung durch ein einziges, JSON-RPC-basiertes Protokoll, das ein Sprachmodell als Client mit beliebig vielen MCP-Servern verbindet — und ein einmal gebauter Server steht damit jedem MCP-fähigen Modell offen.

Technisch ist MCP bewusst nüchtern gehalten: JSON-RPC 2.0 als Nachrichtenformat, zwei vorgesehene Transporte (stdio für lokale Prozesse, HTTP mit Server-Sent Events für entfernte Server), klare Initialisierungs- und Capability-Verhandlung. Keine eigene Authentifizierung im Protokoll selbst — die wird über bewährte Schichten wie OAuth 2.1 oder mTLS oben drauf gelegt.

Verbreitung ist mittlerweile breit: Claude (Desktop, IDE-Integrationen, API), Cursor, VS Code, Zed, n8n, viele Agenten-Frameworks und kommerzielle Plattformen sprechen MCP. Wer heute eine Integration baut, gewinnt mit MCP einen Connector, der nicht morgen wieder umgeschrieben werden muss.

Architektur agentenbasierter Systeme

Ein Agent ist mehr als „Modell plus Tool-Liste". Er ist ein Steuerungsmuster, das Wahrnehmung, Entscheidung und Handlung in einer Schleife verbindet. Welche Variante dieses Musters passt, hängt von Aufgabe, Risiko und Latenzbudget ab.

Querschnittsthemen, die Sie früh klären sollten

Memory (Was merkt sich der Agent zwischen Turns? Vektorstore, Session-Cache, persistierter Verlauf?) · Tool-Auswahl (statisch im Prompt, dynamisch über Embeddings, oder hybrid?) · Mensch-im-Loop (welche Entscheidungen muss ein Mensch bestätigen, bevor sie wirksam werden?) · Modell-Routing (kleines Modell für Klassifikation, großes für Synthese — spart Geld und Latenz) · Beobachtbarkeit (Tracing aller Tool-Calls, Token-Kosten pro Vorgang, Modell-Drift erkennen).

n8n als Orchestrator — was wir aus jahrelanger Praxis gelernt haben

n8n ist eine quelloffene Workflow-Plattform, die uns seit langem in der Integrationsarbeit begleitet — von ersten Webhook-zu-Datenbank-Strecken bis hin zu komplett orchestrierten Agenten-Architekturen mit Tool-Aufrufen, Memory und MCP-Anbindung. Wir kennen die Plattform aus Projekten, in denen es nicht um Spielwiese geht, sondern um Vorgänge, die jeden Tag zuverlässig laufen müssen.

Der Reiz von n8n liegt in seiner doppelten Natur: Auf der Oberfläche eine Low-Code-Leinwand mit über 400 fertigen Integrationen, darunter eine vollwertige Node-/JavaScript-Laufzeit. Ein Vorgang lässt sich also als Klick-Diagramm starten und dort verfeinern, wo Klick-Diagramme an ihre Grenzen stoßen — mit echtem Code, Sub-Workflows oder eigenen Custom-Nodes. Das ist der Punkt, an dem Low-Code-Plattformen üblicherweise scheitern; bei n8n hält die Brücke.

Für Agenten ist n8n besonders attraktiv geworden, seitdem die AI Agent Node existiert: Sie kapselt einen Tool-aufrufenden Agenten als Workflow-Knoten, mit konfigurierbarem Modell, austauschbarem Memory-Anbieter (Buffer, Window, Vector Store) und einer Liste registrierter Tools. Diese Tools können wiederum andere n8n-Workflows sein, HTTP-Requests, Datenbank-Queries — oder eben MCP-Server, die seit Anfang 2025 als first-class Tool-Provider angebunden werden können.

Wir setzen n8n typischerweise als Orchestrierungs-Backbone ein: Die Voice-Plattform spricht mit dem Anrufer, der LLM-Agent entscheidet, welcher Schritt nötig ist, und n8n liefert die deterministischen Strecken — Datenbank-Updates, ERP-Aufrufe, Dokumenten-Generierung, Mailversand. Die Trennung ist bewusst: Der Agent darf flexibel sein, der Geschäftsprozess bleibt geprüft.

Voice-Agenten mit VAPI und ElevenLabs

Sprache ist die natürlichste Schnittstelle — und gleichzeitig die anspruchsvollste. Ein Bürger, der nicht warten will. Eine Versicherte, die ein Anliegen schildert. Eine Anruferin, die zwischen Hochdeutsch, Dialekt und Türkisch wechselt. Voice-Agenten brauchen eine Latenz unter einer Sekunde, eine Stimme, die nicht entgleitet, und eine Anbindung, die echte Vorgänge auslöst. Wir bauen diese Stacks aus zwei Komponenten, die sich in Projekten bewährt haben: VAPI für die Echtzeit-Telefonie-Schicht und ElevenLabs für Sprachausgabe in produktionstauglicher Qualität.

Tools, MCP und Backends — wie der Anrufer zu echten Aktionen kommt

Eine schöne Stimme allein nützt wenig. Der Wert entsteht, sobald der Voice-Agent tatsächlich etwas tut — einen Termin im Fachverfahren legt, eine Rückerstattung anstößt, einen Mängelmelder im OZG-System erfasst. Hier kommt MCP zurück ins Bild: VAPI ruft als MCP-Client Tools auf, die wir auf einem MCP-Server bereitstellen. Der Server ist die kontrollierte Tür zu Backends — ERP, CRM, Fachverfahren, Datenbanken — und implementiert die Geschäftslogik, Validierung und Audit-Spuren.

Praktischer Aufbau einer Bürgertelefonie-Lösung, wie wir ihn typischerweise umsetzen: VAPI nimmt den Anruf an, leitet Audio durch ElevenLabs für die Sprachausgabe, ruft als Tool-Provider unseren MCP-Server an. Der MCP-Server bietet Funktionen wie vorgang_anlegen, terminslots_finden, buergerstatus_pruefen — jede Funktion mit Schema, Validierung und Anbindung an Fachverfahren oder Datenbank. n8n läuft daneben für deterministische Folgeprozesse: Bestätigungs-E-Mails, Übergabe an Sachbearbeiter, Eskalationen.

// Skizze: VAPI Assistant-Konfiguration mit MCP-Server
{
  "model": {
    "provider": "anthropic",
    "model":    "claude-sonnet-4-5",
    "systemPrompt": "Sie sind die freundliche Stimme der Stadt Musterstadt …"
  },
  "voice": {
    "provider": "11labs",
    "voiceId":  "de-formal-female-01"
  },
  "tools": [{
    "type":        "mcp",
    "serverUrl":   "https://mcp.musterstadt.de/sse",
    "auth": { "type": "oauth2", "clientId": "vapi-buergertelefonie" }
  }]
}

Tutorial: Eigenen MCP-Server bauen und produktiv betreiben

Der schnellste Weg, MCP wirklich zu verstehen, ist: einmal selbst einen Server bauen. Diese Anleitung führt Sie kompakt vom ersten Tool über Authentifizierung bis zum produktiven Betrieb. Beispiel: ein MCP-Server für eine kommunale Bürgerterminvergabe.

1. Voraussetzungen

   Eine Node.js-Umgebung ab Version 20 (alternativ Python ab 3.11). Für Produktion: ein Reverse-Proxy mit TLS, ein OAuth-2.0/2.1-fähiger Authorization-Server (z.B. Keycloak — siehe unsere IAM-Seite), und ein anbindbares Backend (Datenbank oder Fachverfahren-API).

2. SDK installieren und Skelett anlegen

   Anthropic stellt offizielle SDKs für TypeScript und Python bereit. Hier in TypeScript, weil n8n und VAPI sich damit nahtlos vertragen.

   npm init -y
   npm install @modelcontextprotocol/sdk zod
   
   // src/server.ts
   import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
   import { StdioServerTransport }
     from "@modelcontextprotocol/sdk/server/stdio.js";
   import { z } from "zod";
   
   const server = new McpServer({
     name: "musterstadt-buergerservice",
     version: "1.0.0"
   });

3. Erstes Tool definieren

   Tools werden mit Name, Beschreibung und einem Zod-Schema für die Parameter registriert. Die Beschreibung ist nicht Beiwerk — das LLM liest sie und entscheidet daraus, wann es das Tool nutzt. Investieren Sie Zeit in präzise, dialogtaugliche Beschreibungen.

   server.tool(
     "terminslots_finden",
     "Findet freie Terminslots im Bürgerbüro für eine Leistung. " +
     "Liefert max. 5 Vorschläge im gewünschten Zeitraum.",
     {
       leistung:    z.enum(["perso", "reisepass", "meldebescheinigung"]),
       von:         z.string().describe("ISO-Datum, frühestens"),
       bis:         z.string().describe("ISO-Datum, spätestens"),
       standort_id: z.number().optional()
     },
     async (input) => {
       const slots = await backend.findSlots(input);
       return { content: [{ type: "text", text: JSON.stringify(slots) }] };
     }
   );

4. Transport wählen — stdio oder HTTP/SSE

   Lokal eingebettete MCP-Server (z.B. eine IDE startet den Server als Kindprozess) nutzen stdio: minimal, ohne Netzwerk-Overhead. Für entfernt erreichbare Server — und damit alles, was VAPI oder einen geteilten n8n-Hub bedient — nutzen wir Streamable HTTP (mit Server-Sent Events). Eine schlanke Express-Anbindung reicht für den Start.

   // HTTP/SSE-Variante
   import express from "express";
   import { StreamableHTTPServerTransport }
     from "@modelcontextprotocol/sdk/server/streamableHttp.js";
   
   const app = express();
   app.use(express.json());
   
   app.post("/mcp", async (req, res) => {
     const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
     await server.connect(transport);
     await transport.handleRequest(req, res, req.body);
   });
   
   app.listen(3000);

5. Authentifizierung über OAuth 2.1

   MCP definiert seit Mitte 2025 einen offiziellen OAuth-2.1-basierten Authorization-Flow. Ihr MCP-Server fungiert als Resource-Server, ein bestehender Authorization-Server (z.B. Keycloak) stellt Access-Tokens aus. Konkret: Der MCP-Client (VAPI, n8n, Claude) holt sich ein Token, der MCP-Server validiert es bei jedem Aufruf — Standard-Resource-Server-Logik, keine Sonderrolle für MCP.

   // Express-Middleware (Auszug)
   app.use("/mcp", async (req, res, next) => {
     const token = req.headers.authorization?.replace("Bearer ", "");
     if (!token) return res.status(401).set(
       "WWW-Authenticate",
       'Bearer resource_metadata="https://mcp.example/.well-known/oauth-protected-resource"'
     ).end();
   
     const claims = await verifyJwt(token, { issuer, audience: "mcp-buergerservice" });
     req.user = claims;
     next();
   });

6. Anbinden an Clients

   Drei typische Clients, alle mit MCP-nativer Unterstützung:

   • Claude Desktop / Claude Code: Eintrag in der Konfiguration, Server-URL plus OAuth-Konfiguration. Tools sind sofort im Chat verfügbar.
   • n8n: Der MCP-Client-Knoten registriert den Server; Tools können direkt im AI Agent Node oder in einem klassischen Workflow genutzt werden.
   • VAPI: Im Assistant-Konfigurations-JSON wird der MCP-Server als Tool-Provider eingetragen (siehe Beispiel oben).

7. Produktiv schalten — Hardening

   Reverse-Proxy mit TLS und Rate-Limits davor. Token-Validierung mit Audience-Check. Strukturierte Logs jedes Tool-Aufrufs (wer rief mit welchen Parametern auf, was kam zurück, wie lange dauerte es). Idempotenz-Schlüssel für schreibende Operationen. Schema-Validierung mit Zod als harter Gate vor Backend-Aufrufen. Health-Endpoints, Tracing über OpenTelemetry, ein Dashboard mit Latenz, Fehlerquote und Token-Verbrauch pro Vorgang.

   docker run -d --name mcp-server \
     -p 3000:3000 \
     -e ISSUER=https://iam.musterstadt.de/realms/buerger \
     -e AUDIENCE=mcp-buergerservice \
     -e DB_URL=postgresql://… \
     --restart unless-stopped \
     registry.example/mcp-buergerservice:1.0.0
   
   # Davor: nginx mit TLS, mTLS für M2M-Clients optional

8. Versionierung und Evolution

   Tools sind Teil Ihrer öffentlichen API — sie ändern Verhalten in produktiven Vorgängen. Behandeln Sie Schema-Änderungen mit der Disziplin einer REST-API: rückwärtskompatible Erweiterungen, deprecation-Phasen, semantische Versionierung im Server-Namen, automatisierte Verträge per Snapshot-Tests. Wer hier sorgfältig arbeitet, kann den Modell-Anbieter wechseln, ohne dass die Geschäftslogik leidet.

Architekturmuster, Sicherheit und Betrieb

Agentenbasierte Systeme bringen neue Risiken mit, die klassische Webanwendungen nicht haben. Prompt-Injection in Eingaben, Tool-Missbrauch durch halluzinierte Argumente, schleichende Modell-Drift, undurchsichtige Token-Kosten. Wer das nüchtern angeht, verhindert die meisten Probleme bevor sie auftreten.

Sechs Prinzipien, die wir in jedem Projekt durchsetzen

1. Least-Privilege auf Tool-Ebene. Jeder MCP-Server bekommt nur die Backend-Rechte, die er für seine Tools braucht — kein Datenbank-Admin, kein „all-scope"-API-Key. Tools selbst werden pro Client-Identität geprüft: ein Voice-Agent darf andere Operationen sehen als ein interner Sachbearbeitungs-Agent.

2. Eingaben validieren, Ausgaben bändigen. Schema-Validierung an der Tool-Grenze ist Pflicht. Daneben: Sanitization von Inhalten, die vom Modell zurück in andere Modelle fließen — sonst wird ein einziger böser Datensatz zur Prompt-Injection-Bombe für alle nachgelagerten Schritte.

3. Mensch-im-Loop, wo Konsequenzen wehtun. Geld bewegen, Berechtigungen ändern, Bürger-Daten löschen — kein Tool führt das ohne explizite Bestätigung aus. Im einfachsten Fall: ein „confirm"-Schritt im Workflow, der die Aktion zur Freigabe an einen Mitarbeiter eskaliert.

4. Vollständige Audit-Trails. Jeder Tool-Aufruf wird strukturiert geloggt — Zeitstempel, Identität, Eingabe, Ausgabe, Latenz, Token-Verbrauch. In regulierten Branchen ist das nicht optional, sondern Bestandteil der Aufsichts-Pflichten.

5. Modelle wechselbar halten. Modelle werden monatlich besser, Preise schwanken, Anbieter haben Ausfälle. Wer sein System gegen ein Provider-Interface baut (statt direkt gegen das SDK eines Anbieters), spart sich teure Migrationen.

6. Kosten von Anfang an messen. Token-Kosten pro Vorgang sind ein Geschäfts-Kennzahl, kein Implementierungs-Detail. Wir loggen sie pro Sub-Agent, pro Tool, pro Vorgangstyp — und können daraus jederzeit eine ehrliche Wirtschaftlichkeitsrechnung ziehen.

Was wir typischerweise mitbringen

Erfahrung aus Projekten mit n8n, Keycloak und Custom-Backends, langjährige Praxis in Java-, .NET- und Python-Ökosystemen, ein klarer Blick auf das, was in regulierten Branchen tragfähig ist — und der Wille, einen Prototyp nicht als Endprodukt zu verkaufen. Agenten sind eine starke Werkzeugklasse, kein Universalheilmittel. Wir erklären offen, wo der Einsatz Sinn ergibt und wo eine klassische Architektur die ehrlichere Antwort ist.