Wann man dazu greift
- Tools und Datenquellen über verschiedene Frameworks hinweg nutzbar sein müssen.
- Lokale oder externe Systeme verbunden werden müssen.
- Kontextzugriff standardisiert werden soll.
MCP.
Tools sprechen ein gemeinsames Protokoll.
Externe Ressourcen und Tools werden über das Model Context Protocol als standardisierte Integrationsschicht bereitgestellt.
In der PraxisEin Coding-Assistent verbindet sich über eine einzige MCP-Transportschicht mit einem lokalen Dateisystem-Server und einem entfernten GitHub-Server, ohne für jeden einen eigenen Integrationscode zu schreiben.
Wann es nach hinten losgeht
- Direkte SDK-Integration einfacher und ausreichend ist.
- Das Sicherheitsmodell unklar ist.
- Der Protokollbetrieb mehr Komplexität als Wert einführt.
Die Abwägung
Breite Interoperabilität wird auf Kosten zusätzlichen Betriebs- und Berechtigungsverwaltungsaufwands gewonnen.
Eine Form, die du auf eine Serviette zeichnen kannst.
Stell dir eine universelle Steckdose vor. Vor MCP hatte jedes Tool, das ein Agent nutzen wollte, seinen eigenen Stecker — ein anderes SDK, Schema und Auth-Modell. N Agenten an M Tools anzubinden bedeutete N×M maßgeschneiderte Integrationen.
MCP reduziert das auf N + M. Ein Tool-Autor schreibt einen Server; eine Agenten-Runtime liefert einen Client. Jedes Tool, das das Protokoll spricht, lässt sich an jeden Agenten anschließen, der es spricht — ohne maßgeschneiderte Verdrahtung. Es ist, in Anthropics Worten, „ein USB-C-Port für KI-Anwendungen.“
Was es tatsächlich tut.
Ein Standardprotokoll verbindet Host und Tool-Server.
Drei Rollen, eine zustandsbehaftete Verbindung.
MCP folgt einer Client-Server-Architektur, die vom Language Server Protocol übernommen wurde. Ein Host betreibt einen oder mehrere Clients; jeder Client hält eine dedizierte Verbindung zu einem Server. Nachrichten sind JSON-RPC 2.0, übertragen über stdio bei lokalen Servern oder Streamable HTTP bei entfernten.
initialize → Capability-Aushandlung → Discovery → Betrieb
Host
Die KI-Anwendung, die der Nutzer tatsächlich bedient — Claude Desktop, ein IDE-Plugin oder deine Agenten-Runtime. Sie besitzt das LLM, die Konversation und die Entscheidung, ein Tool zu nutzen. Sie startet Clients nach Bedarf.
Client
Ein Konnektor innerhalb des Hosts, der eine 1:1 zustandsbehaftete Sitzung mit genau einem Server unterhält. Er führt den Handshake durch, leitet Anfragen weiter und hält die Capabilities synchron.
Server
Ein Programm — lokal oder entfernt —, das Capabilities über MCP bereitstellt. Der Tool-Autor schreibt es einmal; jeder konforme Client kann dann entdecken und aufrufen, was es anbietet.
Drei Server-Primitive.
Tools
ModellgesteuertAusführbare Funktionen, die das Modell aufrufen kann, um eine Aktion durchzuführen oder Live-Daten abzurufen. Entdeckt über tools/list, aufgerufen über tools/call.
search_flights(from, to, date)
create_issue(repo, title, body)
Resources
AnwendungsgesteuertSchreibgeschützte Kontextdaten, identifiziert per URI — Dateien, Zeilen, Dokumente —, die der Host ohne Aktion in das Kontextfenster des Modells ziehen kann.
file:///logs/2026-05.txt
postgres://schema/tickets
Prompts
NutzergesteuertWiederverwendbare, parametrisierte Vorlagen, die der Server anbietet — dem Nutzer als Slash-Befehle oder Menüaktionen präsentiert, die einen bekannten Workflow vorpaketieren.
/summarize-pr pr=482
/triage-bug id=ENG-19
Die Verbindung läuft in beide Richtungen. Ein Server kann auch in den Host zurückrufen, über sampling (das LLM des Hosts um eine Vervollständigung bitten), elicitation (den Nutzer um weitere Eingaben bitten) und roots (erfahren, welche Dateisystemgrenzen er berühren darf). Diese Zwei-Wege-Fähigkeit ist es, die MCP von einer einfachen Tool-Calling-API unterscheidet.
Ein realer Ablauf, Nachricht für Nachricht.
AufgabeWas waren unsere drei häufigsten Support-Probleme letzte Woche?
InitializeDer Client des Hosts öffnet eine Sitzung und sendet initialize. Client und Server tauschen Protokollversion und Capabilities aus — der Server gibt bekannt, dass er tools und resources hat.
DiscoverDer Client ruft tools/list auf. Der Postgres-Server liefert ein Tool — query_tickets(sql) — samt seinem JSON Schema zurück, sodass das Modell nun weiß, dass das Tool existiert und wie die Argumente zu formen sind.
ReasonDas Modell entscheidet, dass es aggregierte Zählungen braucht, und wählt query_tickets, indem es SQL entwirft, das Tickets der letzten 7 Tage nach Kategorie gruppiert.
tools/callquery_tickets(sql="SELECT category, COUNT(*) … WHERE created > now() - interval '7 days' GROUP BY 1 ORDER BY 2 DESC LIMIT 3")
ResultDer Server führt die Abfrage gegen die Datenbank aus und liefert strukturierte Inhalte zurück: Billing 142 · Login 98 · Sync 61.
AnswerDie drei häufigsten Probleme letzte Woche: Billing (142), Login-Probleme (98) und Sync-Fehler (61).
Der Sinn des Protokolls: Richte denselben Agenten stattdessen auf einen GitHub-MCP-Server, und er beantwortet Fragen zu Pull Requests — ohne eine Zeile neuen Integrationscode. Discovery, Schemas und Aufruf sind identisch, weil alles über denselben Standard läuft.
Das Protokoll in der Praxis.
Server · Pythonpython
# server.py — expose a database as an MCP server
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("support-tickets")
@mcp.tool()
def query_tickets(sql: str) -> list[dict]:
"""Run a read-only SQL query against the tickets database."""
return db.execute(sql).fetchall()
@mcp.resource("postgres://schema/tickets")
def schema() -> str:
"""The tickets table schema, so the model can read column names."""
return open("schema.sql").read()
if __name__ == "__main__":
# stdio for local; switch to transport="streamable-http" for remote
mcp.run(transport="stdio")MCP und A2A ergänzen sich, statt zu konkurrieren.
Zwei offene Protokolle überqueren die Grenze eines einzelnen Frameworks. MCP standardisiert, wie ein Agent mit einem Tool spricht; A2A standardisiert, wie ein Agent mit einem anderen Agenten spricht. Häufig werden beide eingesetzt.
Dimension
MCP
A2A
Scope
Agent ↔ Tool / Daten
Agent ↔ Agent
Standardisiert
Tool-Discovery, Aufruf, strukturiertes I/O
Agent-Discovery, Task-Lebenszyklus, Artefakt-Austausch
Kernartefakte
Resources, Tools, Prompts
Agent Cards, Tasks, Artifacts
Initiator
Agent (Client) ruft MCP-Server auf
Jeder Agent kann initiieren; Tasks haben einen definierten Lebenszyklus
Trägerorganisation
Anthropic (offene Spezifikation)
Linux Foundation (initiiert von Google, April 2025)
Kapselungsmodell
Tool legt seine Capability-Oberfläche offen; Agent besitzt das Reasoning
Agenten sind füreinander opak; interner Zustand bleibt privat
Drei Wege, wie dieses Pattern Probleme verursachen kann.
MCP als Netzwerkprimitiv behandeln
Teams exponieren interne Datenbanken über MCP ohne Authentifizierungsprüfungen und behandeln die Protokollschicht als Sicherheitsgrenze.
Lösung · Authentifizierung auf der MCP-Server-Ebene erzwingen, nicht nur auf dem Transport. Jede exponierte Ressource auf Minimalrechte prüfen.
Instabile Schemas bei schneller Iteration
Der MCP-Server ändert sein Schema wöchentlich. Client-Agenten brechen, weil sie an einer veralteten Tool-Definition hängen.
Lösung · MCP-Schemas versionieren und ein Kompatibilitätsfenster unterstützen. Clients ablehnen, die keinen Versions-Header deklarieren.
Überladung der Tool-Menge
Ein Client bindet ein Dutzend Server ein; das Modell sieht nun 80 Tools und wählt das falsche — oder verharrt bei der Auswahl.
Lösung · Nur die Server einbinden, die eine Aufgabe benötigt. Tools pro Route eingrenzen und Namen sowie Beschreibungen eindeutig halten.
Wo MCP nativ ist.
Microsoft Agent FrameworkMicrosoft unterstützt MCP; A2A-MitinitiatorNativ
Claude DesktopReferenz-Host — lokale stdio-ServerNativ
Nächstes Pattern