MCP (Model Context Protocol)

Kurz: Offenes Protokoll, mit dem eine KI wie Claude über einen einheitlichen Kanal auf externe Tools und Datenquellen zugreifen kann (Dateien, APIs, Apps), ohne dass für jede App eine eigene Integration geschrieben werden muss.

Genauer: Ein MCP-Server bietet “Tools” (aufrufbare Funktionen) über eine standardisierte Schnittstelle an – als Transport dient z. B. stdio, SSE oder Streamable HTTP. Der Client (hier Claude Code) verbindet sich, bekommt eine Liste verfügbarer Tools, und ruft sie danach wie eingebaute Tools auf.

Kontext bei uns: Dein Obsidian-Vault wird per MCP angebunden – das Plugin “MCP Connector” (istefox) startet in Obsidian einen lokalen MCP-Server (http://127.0.0.1:27200/mcp), den wir mit claude mcp add --transport http in Claude Code registriert haben, authentifiziert über ein Bearer Token.

Im Detail

Die drei Kernbausteine

Die drei Kernbausteine, die ein MCP-Server einem Client wie Claude anbieten kann: Tools (aufrufbare Funktionen mit definierten Parametern, z. B. “lies diese Datei” oder “sende diese Nachricht”), Resources (lesbare Daten wie Dateien oder Datenbankeinträge, die der Client bei Bedarf abrufen kann, meist ohne Seiteneffekte) und Prompts (vordefinierte, wiederverwendbare Prompt-Vorlagen, die der Server bereitstellt, damit Nutzer häufige Anfragen nicht jedes Mal neu formulieren müssen). In der Praxis werden bislang am häufigsten Tools genutzt, da sie dem Modell die größte Handlungsfähigkeit geben — Resources und Prompts sind eher unterstützende Bausteine.

Warum ein offener Standard

Der entscheidende Vorteil von MCP als offenem Standard: Ohne ihn bräuchte jede KI-Anwendung eine eigene, maßgeschneiderte Integration für jede externe App (eine für Obsidian, eine für Slack, eine für GitHub, …) — mit MCP kann ein einziger, von der jeweiligen App-Community bereitgestellter Server von JEDEM MCP-fähigen Client genutzt werden, ohne dass der Client-Hersteller diese Integration selbst schreiben muss. Das ist vergleichbar mit dem Unterschied zwischen proprietären Ladekabeln und einem einheitlichen USB-Standard — vor einem solchen Standard musste jeder Hersteller sein eigenes Kabel für jedes Gerät mitliefern, danach reicht ein einziges Kabelformat für praktisch alles.

Verbindungsarten (Transports)

Der Transport bestimmt, WIE Client und Server tatsächlich Daten austauschen. stdio (Standard-Ein-/Ausgabe) eignet sich für lokal laufende Server, die der Client selbst als Subprozess startet — einfach, aber an denselben Rechner gebunden. SSE (Server-Sent Events) und Streamable HTTP erlauben dagegen Verbindungen zu entfernt laufenden Servern über das Netzwerk, inklusive Authentifizierung (z. B. per Bearer Token) — praktisch, wenn der MCP-Server nicht auf demselben Gerät läuft wie der Client, sondern z. B. in Obsidian als lokal laufender, aber über HTTP erreichbarer Dienst.

Sicherheitsaspekte

Da ein MCP-Server dem Client potenziell weitreichende Fähigkeiten gibt (Dateizugriff, Netzwerkzugriff, Ausführung von Aktionen in externen Apps), ist die Frage, WELCHE Server man mit WELCHEN Berechtigungen verbindet, sicherheitsrelevant — ein bösartiger oder kompromittierter MCP-Server könnte theoretisch Daten exfiltrieren oder unerwünschte Aktionen auslösen. Seriöse MCP-Clients zeigen deshalb typischerweise an, welche Tools ein neu verbundener Server anbietet, und lassen den Nutzer einzelne, potenziell riskante Aktionen (z. B. Datei-Löschungen) explizit bestätigen, statt dem Modell blind freie Hand zu geben.

Entstehungskontext

MCP wurde von Anthropic als offener Standard veröffentlicht, mit dem expliziten Ziel, die Fragmentierung bei KI-Tool-Integrationen zu verringern — ähnlich wie das Language Server Protocol (LSP) zuvor die Integration von Programmiersprachen-Unterstützung in verschiedene Code-Editoren vereinheitlicht hat, statt dass jeder Editor eine eigene Implementierung für jede Sprache bräuchte.

Siehe auch: Streamable HTTP, Bearer Token, Obsidian Vault, Protokoll