Grundlagen

MCP: Wie KI-Tools miteinander reden

Das Model Context Protocol verbindet KI-Assistenten mit Tools und Daten. 97 Millionen Downloads in 16 Monaten. Was MCP ist und warum es dich betrifft.

Du nutzt Claude und willst, dass es deine Jira-Tickets liest. Gleichzeitig soll es deinen Code auf GitHub reviewen und die Ergebnisse in Slack posten. Wie verbindest du das?

Früher: Für jede Kombination aus KI-Tool und externem Dienst eine eigene Integration bauen. Bei 5 KI-Tools und 10 Diensten sind das 50 Integrationen.

Heute: Model Context Protocol (MCP). Jeder Dienst baut einen MCP-Server, jedes KI-Tool einen MCP-Client. Bei 5 KI-Tools und 10 Diensten sind das 15 Bausteine statt 50.

Was MCP ist

MCP ist ein offenes Protokoll, das standardisiert, wie KI-Anwendungen mit externen Tools und Datenquellen kommunizieren. Der häufigste Vergleich: USB-C für KI. Ein Stecker, der überall passt.

Technisch basiert MCP auf JSON-RPC 2.0. Die aktuelle Spezifikation heißt 2026-07-28, Versionen tragen immer das Datum der letzten inkompatiblen Änderung. MCP kennt drei Rollen:

  • Host: Die KI-Anwendung (Claude Desktop, Cursor, VS Code)
  • Client: Verwaltet die Verbindung zu einem MCP-Server (lebt im Host)
  • Server: Stellt Fähigkeiten bereit, die die KI nutzen kann

Ein MCP-Server bietet drei Arten von Fähigkeiten an:

  • Tools: Funktionen, die die KI aufrufen kann (Datenbank abfragen, GitHub-Issue erstellen, E-Mail senden)
  • Resources: Daten, die die KI lesen kann (Dateien, Datenbank-Schemas, API-Antworten)
  • Prompts: Vorlagen für häufige Aufgaben

97 Millionen Downloads in 16 Monaten

Anthropic hat MCP im November 2024 veröffentlicht. Im März 2026 erreichten die SDKs (Python + TypeScript) 97 Millionen monatliche Downloads. Zum Vergleich: React hat für 100 Millionen monatliche Downloads etwa 3 Jahre gebraucht. MCP hat das in 16 Monaten geschafft.

Das Server-Angebot wächst entsprechend mit: Im März 2026 zählte die Bestandsaufnahme 5.800 Server, im MCP Server Directory sind es Ende Juli 2026 über 9.800 offizielle und Community-Server. Für die meisten gängigen Dienste gibt es also längst einen fertigen Server.

Wer MCP unterstützt

Die wichtigsten Plattformen:

KI-Anbieter: Claude (nativ), OpenAI (GPT-Modelle), Google (Gemini), Mistral, xAI (Grok), Cohere

Entwicklungsumgebungen: Claude Desktop, Claude Code, Cursor, VS Code (via GitHub Copilot), Windsurf, Zed, Replit

Das bedeutet: Ein MCP-Server, den du einmal baust, funktioniert in all diesen Umgebungen. Kein Vendor-Lock-in, kein Umschreiben beim Tool-Wechsel.

Praktische Beispiele

Datenbanken: PostgreSQL, MySQL, SQLite, Neon. Die KI kann Schemas lesen, Queries ausführen und Ergebnisse analysieren.

Entwickler-Tools: GitHub (Repos, Issues, PRs), GitLab, Docker, Playwright (Browser-Automatisierung), Filesystem (lokale Dateien lesen/schreiben).

Produktivität: Notion, Slack, Jira, Google Calendar, Gmail, Figma, Canva.

Cloud: AWS, GCP, Azure Integrationen.

Ein konkretes Szenario: Du verbindest Claude mit einem GitHub-Server und einem Jira-Server. Dann kannst du sagen: "Schau dir die offenen Bugs in Jira an, prüfe ob es dazu schon PRs auf GitHub gibt, und erstelle eine Zusammenfassung." Claude versteht, welche Tools es braucht und ruft sie selbständig auf.

MCP vs. Function Calling

Wenn du mit der OpenAI API oder der Anthropic API gearbeitet hast, kennst du Function Calling (bei Anthropic: Tool Use). Wie unterscheidet sich MCP davon?

Function Calling ist ein Feature auf Request-Ebene: Du sagst dem Modell bei jedem API-Call, welche Funktionen verfügbar sind. Das ist gut für einfache Anwendungen mit 2-3 Tools.

MCP ist eine Infrastruktur-Schicht: Eine standardisierte Schnittstelle zwischen KI und Tools, mit dynamischer Tool-Erkennung, Zugriffsrechten und Versionierung. Das ist für produktive Systeme mit vielen Integrationen.

Seit der Spezifikation 2026-07-28 ist MCP dabei zustandslos. Früher erledigte ein initialize-Handshake zwei Dinge auf einmal: Er handelte Version und Fähigkeiten aus und öffnete eine Session, an die alle weiteren Requests gebunden waren. Heute reist die Aushandlung in jedem einzelnen Request mit, und der Sessionzustand entfällt ersatzlos. Weil jeder Request alles mitbringt, was zu seiner Bearbeitung nötig ist, kann ihn jede Serverinstanz beantworten. Praktisch heißt das: MCP verhält sich wie ein normaler HTTP-Service und läuft hinter einem gewöhnlichen Load Balancer.

In der Praxis ergänzen sich beide. MCP übersetzt seine Tool-Definitionen automatisch in das Function-Calling-Format des jeweiligen Anbieters. Du musst dich nicht entscheiden, MCP nutzt Function Calling unter der Haube.

Warum MCP für Agenten wichtig ist

KI-Agenten, die autonom mehrere Schritte ausführen, brauchen Zugang zu externen Systemen. MCP löst genau dieses Problem:

  • Dynamische Tool-Erkennung: Der Agent fragt zur Laufzeit über server/discover, welche Tools und Protokollversionen ein Server anbietet, und wählt die passenden aus
  • Multi-Server-Komposition: Ein Agent kann gleichzeitig mit Datenbank, GitHub, Slack und Dateisystem arbeiten
  • Langläufige Aufgaben: Über die Tasks-Extension (io.modelcontextprotocol/tasks) fragt der Client den Fortschritt per Polling ab, statt eine offene Verbindung zu halten

Im Dezember 2025 hat Anthropic MCP an die Agentic AI Foundation (AAIF) unter dem Dach der Linux Foundation übergeben. Mitgründer sind OpenAI und Block, unterstützt von AWS, Google, Microsoft und Salesforce. Das ist ein starkes Signal, dass MCP kein proprietärer Standard bleiben soll. Seit dem Übergang gibt es auch eine formale Deprecation-Policy: Features, die verschwinden sollen, bleiben mindestens zwölf Monate in der Spezifikation.

Was die Spec 2026-07-28 geändert hat

Am 28.07.2026 kam die größte Revision seit dem Start. Die Punkte, die im Alltag ankommen:

ÄnderungAuswirkung
Handshake und Session-ID gestrichenServer skalieren horizontal, ohne Sticky Routing und ohne gemeinsamen Session-Store
Header-basiertes Routing über Mcp-Method und Mcp-NameGateways und Firewalls können filtern, ohne den JSON-Body zu lesen
Cachebare Listen mit ttlMs und cacheScopeWeniger Roundtrips für Tool-Kataloge, die sich selten ändern
Issuer-Validierung nach RFC 9207 verpflichtendSchutz gegen OAuth-Mixup-Angriffe
Roots, Sampling, Logging und HTTP+SSE deprecatedFunktionieren weiter, mindestens zwölf Monate Übergangsfrist

Bestehende Server müssen nicht sofort umziehen. Clients dürfen beide Generationen bedienen ("dual-era"), und solange sie das tun, laufen alte Server unverändert weiter. Der Migrationsaufwand steckt vor allem dort, wo eigener Code die Session-ID für Zustand, Logging oder Rate Limiting benutzt hat. Details und die vollständige Kompatibilitätsmatrix stehen in MCP wirft den Session-State raus.

Sicherheit: Worauf du achten musst

MCP erweitert die Angriffsfläche deiner KI-Anwendung. Ein paar Dinge, die du wissen solltest:

Prompt Injection über Tool-Outputs. Wenn ein MCP-Server Daten zurückgibt, die von externen Quellen stammen (z.B. eine Webseite, eine E-Mail), könnten diese manipulierte Anweisungen enthalten. Das Modell könnte sie als Instruktionen interpretieren.

Berechtigungen. Ein MCP-Server mit Schreibzugriff auf deine Datenbank ist mächtig. Konfiguriere Server nach dem Least-Privilege-Prinzip: Nur die Rechte, die wirklich nötig sind.

Unbekannte Server. Die 10.000+ Server in den Registries sind nicht alle gleich vertrauenswürdig. Prüfe, wer den Server pflegt, bevor du ihn an deine Produktivsysteme hängst.

Die MCP Security Standard v1.1 empfiehlt OAuth 2.1 für Authentifizierung, kurzlebige Access Tokens und rollenbasierte Zugriffskontrolle. Für Enterprise-Einsatz ist das Pflicht.

Die Spec 2026-07-28 zieht hier zusätzlich an: Die Issuer-Validierung nach RFC 9207 ist verpflichtend, Client-Credentials gelten nur für den Issuer, der sie ausgegeben hat, und Dynamic Client Registration wird zugunsten von Client ID Metadata Documents zurückgedrängt. Wenn ein eigener MCP-Server erreichbar im Netz steht, sind das die drei Punkte, die zuerst auf die Liste gehören.

Wie diese Angriffsflächen konkret aussehen und was praktisch dagegen hilft, vertieft MCP- und Connector-Sicherheit. Die konkrete OAuth-Absicherung eines MCP-Servers zeigt MCP-Server absichern: OAuth mit Spring AI.

Erste Schritte

Fertige Server nutzen: Schau auf mcpservers.org nach einem Server für deinen Anwendungsfall. Die meisten lassen sich in wenigen Minuten in Claude Desktop oder Cursor einrichten.

Eigenen Server bauen (TypeScript):

npm install @modelcontextprotocol/server zod

Das TypeScript-SDK ist mit Version 2 in die Pakete @modelcontextprotocol/core, /server und /client aufgeteilt. Das alte Bundle @modelcontextprotocol/sdk läuft auf der 1.x-Linie weiter, spricht aber die alte Protokollgeneration.

Du definierst Tools mit JSON-Schema für Input und Output, implementierst die Handler und wählst den Transport (stdio für lokal, Streamable HTTP für remote). Ein einfacher Server mit 2-3 Tools ist in unter einer Stunde gebaut.

Eigenen Server bauen (Python):

pip install "mcp>=2.0"

Das Python-SDK nutzt Decorators, um Tools zu definieren. Der Einstieg ist sehr ähnlich.

Die offizielle Dokumentation hat Schritt-für-Schritt-Tutorials für beide Sprachen.

Java/Kotlin-Teams: Spring AI (ab Version 1.1) hat MCP als First-Class-Feature integriert. Mit @McpTool-Annotationen kannst du bestehende Spring-Services direkt als MCP-Server bereitstellen. Mehr dazu in unserem Artikel MCP-Server mit Spring AI bauen.

Aktualisierungen
  • 30.07.2026: Auf die Spezifikation 2026-07-28 aktualisiert. Neuer Abschnitt zu den Änderungen (zustandsloses Protokoll, Header-Routing, cachebare Listen, Deprecations), Abgrenzung zu Function Calling und Agenten-Abschnitt korrigiert, verschärfte Autorisierungsanforderungen ergänzt, SDK-Installation auf die 2.x-Pakete umgestellt. Zahl der verfügbaren MCP-Server berichtigt (war unbelegt) und auf den aktuellen Stand gebracht.
Quellen8