MCP erklärt: das USB-C für KI-Tools, MBA Training

# MCP erklärt: das USB-C für KI-Tools

Vor USB-C hatte jedes Gerät sein eigenes Ladegerät, und wer zwei Dinge verbinden wollte, suchte erst einmal den passenden Dongle. Das Model Context Protocol (MCP) leistet für KI-Tools, was USB-C für Kabel geleistet hat: Es definiert einen offenen Standard, sodass jede KI-Anwendung über eine einzige, vorhersehbare Schnittstelle mit jedem Tool sprechen kann.

Das ist relevant, weil Sie die Alternative schon kennen. Jedes Mal, wenn Sie Claude mit individuellem Glue Code an eine neue Datenquelle anbinden, bauen Sie eine Einzelintegration, die nur Sie pflegen. MCP ersetzt diesen Wildwuchs durch einen gemeinsamen Vertrag. Sie bauen einen Connector einmal, und jede MCP-fähige App kann ihn nutzen.

Anthropic hat MCP als offenen Standard eingeführt, die vollständige Spezifikation liegt auf modelcontextprotocol.io. Es ist nicht Claude-exklusiv. Aber Claude war der erste große Assistent, der es breit übernommen hat, weshalb es in den Claude-Apps, in Claude Code und im Connector-Marketplace auftaucht.

Die drei Bausteine: Host, Client, Server

MCP hat genau drei Rollen. Sobald Sie sie benennen können, fügt sich jede Integration, von der Sie lesen, an ihren Platz.

Der Host

Der Host ist die KI-Anwendung, mit der der Nutzer tatsächlich interagiert. Claude Desktop ist ein Host. Claude Code ebenfalls. Und auch die Claude-Web- und Mobile-App, wenn Sie einen Connector hinzufügen. Der Host besitzt die Konversation, führt das Modell aus und entscheidet, welche Tools das Modell erreichen darf.

Denken Sie an den Host als den Laptop. Er ist das Ding mit dem USB-C-Port.

Der Client

Der Client ist ein kleiner Connector, der im Host lebt und eine Verbindung zu einem Server verwaltet. Der Host startet für jeden Server, mit dem er spricht, einen eigenen Client. Wenn Claude Desktop sich mit Ihrem Wiki und Ihrem Kalender verbindet, sind das zwei Clients, die jeweils einen saubjren, isolierten Kanal offen halten.

Sie berühren den Client selten direkt. Er ist Infrastruktur, die der Host für Sie verwaltet. Denken Sie an ihn als den USB-C-Controller-Chip: unsichtbar, aber er setzt das Protokoll auf Host-Seite durch.

Der Server

Auf dem Server passiert die interessante Arbeit. Ein MCP-Server ist ein eigenständiges Programm, das dem Host Fähigkeiten bereitstellt: Tools, die er aufrufen kann, Resources, die er lesen kann, und Prompts, die er nutzen kann. Sie schreiben Server (oder installieren welche, die andere geschrieben haben), um Claude mit Ihren tatsächlichen Systemen zu verbinden.

Der Server ist das Gerät am anderen Ende des Kabels: ein Wiki, eine Datenbank, ein GitHub-Repo, ein Ticketsystem.

Der Ablauf ist immer gleich. Der Host startet einen Client. Der Client verbindet sich mit einem Server. Der Server macht bekannt, was er kann. Das Modell, das im Host läuft, entscheidet, wann es diese Fähigkeiten aufruft, und der Client leitet die Anfrage weiter.

Was ein Server tatsächlich bereitstellt

Ein MCP-Server spricht in drei Substantiven. Lernen Sie diese, und Sie können den Quellcode jedes Servers lesen.

Tools: Aktionen, die das Modell aufrufen kann, etwa search_wiki oder create_ticket. Das sind Funktionen mit typisierten Eingaben. Das Modell entscheidet sich, sie aufzurufen.
Resources: Daten, die der Host lesen kann, etwa eine bestimmte Wiki-Seite oder eine Datei. Denken Sie an Read-only-Kontext, den der Nutzer oder das Modell hereinzieht.
Prompts: wiederverwendbare Prompt-Vorlagen, die der Server anbietet, etwa ein „summarize this incident“-Workflow, den der Nutzer auslösen kann.

Die meisten Server, die Sie bauen, stützen sich stark auf Tools. Dort liegt der Nutzen.

Ein konkretes Beispiel: Ihr Team-Wiki für Claude verfügbar machen

Angenommen, Ihr Team betreibt ein internes Wiki. Die Engineers vergessen ständig, wo das On-Call-Runbook liegt, und Sie wollen, dass Claude die Frage „Wie lautet unsere Deploy-Rollback-Prozedur?“ beantwortet, indem es tatsächlich das Wiki durchsucht, statt zu raten.

Sie bauen einen MCP-Server, der ein Tool bereitstellt: search_wiki. Hier ist er, mit dem offiziellen Python-SDK im modernen FastMCP-Stil.

python

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("team-wiki")

WIKI_API = "https://wiki.internal.acme.com/api/search"

@mcp.tool()
async def search_wiki(query: str, limit: int = 5) -> str:
    """Search the internal team wiki and return matching page snippets."""
    async with httpx.AsyncClient() as client:
        resp = await client.get(WIKI_API, params={"q": query, "limit": limit})
        resp.raise_for_status()
        hits = resp.json()["results"]

    if not hits:
        return f"No wiki pages found for: {query}"

    return "\n\n".join(
        f"# {h['title']}\n{h['url']}\n{h['snippet']}" for h in hits
    )

if __name__ == "__main__":
    mcp.run()

Das ist ein vollständiger, funktionierender Server. Der Decorator @mcp.tool() verwandelt eine einfache Python-Funktion in eine Fähigkeit, die Claude aufrufen kann. Der Docstring ist keine Dekoration: Der Host schickt ihn an das Modell, damit Claude weiß, *wann* es zu diesem Tool greifen soll. Die Type Hints (query: str, limit: int) werden zum Input-Schema, gegen das der Client validiert.

Beachten Sie, was Sie nicht getan haben. Sie haben nichts Claude-Spezifisches geschrieben. Sie haben nicht den Output des Modells geparst oder Tool-Call-JSON von Hand formatiert. Das Protokoll übernimmt all das. Wenn Ihr Kollege nächstes Jahr einen anderen MCP-Host verwendet, funktioniert genau dieser Server weiterhin.

Anbindung an Claude Desktop

Damit Claude Desktop (ein Host) Ihren Server lädt, registrieren Sie ihn in der MCP-Konfigurationsdatei des Hosts. Auf einem Entwicklerrechner sieht das so aus:

json

{
  "mcpServers": {
    "team-wiki": {
      "command": "python",
      "args": ["/Users/you/servers/wiki_server.py"]
    }
  }
}

Starten Sie den Host neu, und Claude sieht nun search_wiki in seinem Werkzeugkasten. Fragen Sie „Wie lautet unsere Rollback-Prozedur?“, und Claude entscheidet, das Tool aufzurufen, der Client leitet die Anfrage an Ihren Server, Ihr Server fragt das Wiki ab, und die Snippets fließen als fundierter Kontext zurück in die Konversation.

Das ist das gleiche Muster hinter den Connectors, die Sie in den Claude-Apps und im Connector-Marketplace sehen: vorgefertigte MCP-Server für verbreitete Tools (Google Drive, GitHub und mehr), die Sie mit einem Klick aktivieren, statt eine Konfigurationsdatei zu bearbeiten. Unter der Haube sind ein Marketplace-Connector und Ihr selbstgebauter Wiki-Server dasselbe.

Building Your First MCP Server

Watch on YouTube

Transports: lokal vs. remote

Wie spricht der Client eigentlich mit dem Server? MCP definiert zwei wesentliche Transports, also die Kanäle, über die die Nachrichten laufen.

stdio: Der Host startet den Server als lokalen Subprozess und kommuniziert über Standard-Input/Output. Das nutzt die Konfiguration oben. Gut für lokale Tools und die Entwicklung.
Streamable HTTP: Der Server läuft als remote Webservice, und der Host verbindet sich über HTTP. So funktionieren gehostete Connectors und teamweite Server, wenn Sie nicht wollen, dass jeder Mitarbeiter einen Python-Prozess auf seinem Laptop laufen lässt.

Für Ihren Wiki-Server ist stdio während der Entwicklung perfekt. Wenn Sie ihn im Team teilen wollen, deployen Sie dieselbe Logik hinter einem HTTP-Endpoint und richten alle Hosts auf die URL aus.

Wissenscheck

1. Welches Kernproblem will MCP bei KI-Tool-Integrationen lösen?

2. Wofür steht der Host in der USB-C-Analogie der Lektion?

3. Wenn Claude Desktop sich sowohl mit Ihrem Wiki als auch mit Ihrem Kalender verbindet, wie viele Clients verwaltet der Host?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die die Rolle des MCP-Servers korrekt beschreiben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Aussagen, die zu Wesen und Umfang von MCP zutreffen.

Wählen Sie alle richtigen Antworten aus.

Wo MCP im breiteren Claude-Ökosystem sitzt

MCP ist das Bindegewebe, aber es hilft zu sehen, wie es sich zu den anderen Bausteinen verhält, die Sie nutzen werden.

Das Claude Agent SDK dient dazu, autonome Agents im Code zu bauen. Wenn dieser Agent externe Systeme berühren muss, nutzt er MCP-Server als seine Tools. MCP ist also kein Konkurrent des Agent SDK; es ist der Standard, über den das SDK sich an die Welt ansteckt. Dasselbe gilt für Claude Code: Sie können MCP-Server zu Claude Code hinzufügen, damit es während der Arbeit Ihren Issue Tracker durchsuchen oder eine Datenbank abfragen kann.

Skills sind eine andere Schicht. Ein Skill verpackt Instruktionen, Skripte und Ressourcen, die Claude beibringen, *wie* eine Prozedur gut ausgeführt wird. Bei MCP geht es um *Konnektivität* (ein System erreichen); bei Skills um *Fähigkeit* (wissen, wie eine Aufgabe erledigt wird). Ein gut gestaltetes Setup nutzt oft beides: einen Skill, der Ihren Incident-Response-Prozess beschreibt und dabei MCP-Tools aufruft, die Ihre Monitoring-Dashboards auslesen.

Die Messages API ist die Low-Level-Ebene. Wenn Sie Ihren eigenen Host von Grund auf bauen, wickeln Sie dort die Modellaufrufe ab und verdrahten MCP in Ihre eigene Client-Logik. Die meisten Teams müssen nicht so tief gehen, aber es ist gut, die Schichtung zu kennen. Die offizielle Dokumentation auf docs.claude.com behandelt die API, das Agent SDK und Connectors im Detail, und github.com/anthropics enthält die SDKs und Referenzserver.

Das Mental Model: MCP standardisiert den *Port*, das Agent SDK und Skills entscheiden, *was Sie tun, sobald verbunden ist*, und die Messages API ist der *Motor* darunter.

Sicherheit: der Teil, den man überspringt

Ein USB-C-Port kann Ihr Handy laden oder Ihre Festplatte löschen, je nachdem, was eingesteckt ist. Mit MCP ist es dasselbe. Ein Server, den Sie installieren, läuft mit dem Zugriff, den Sie ihm geben, und das Modell kann entscheiden, seine Tools aufzurufen.

Drei Gewohnheiten halten Sie sicher:

1. Installieren Sie nur Server, denen Sie vertrauen. Ein bösartiger Server kann Daten exfiltrieren oder destruktive Aktionen ausführen. Behandeln Sie einen MCP-Server von Dritten wie jede andere Abhängigkeit, die Sie prüfen würden.

2. Vergeben Sie Server-Rechte eng. Ihr Wiki-Server sollte ein Read-only-API-Token haben, keine Admin-Zugangsdaten. Wenn ein Tool nur suchen muss, geben Sie ihm nicht die Möglichkeit zu löschen.

3. Halten Sie bei destruktiven Tools Menschen im Loop. Hosts wie Claude Desktop fragen vor der Ausführung von Tools nach Freigabe. Deaktivieren Sie das nicht für irgendetwas, das schreibt oder löscht.

Das Protokoll gibt Ihnen Reichweite. Für den Blast Radius sind Sie verantwortlich.

Warum das eine große Sache ist

Der stille Gewinn von MCP ist Komponierbarkeit. Sobald Ihr Wiki, Ihr Ticketsystem und Ihr Monitoring alle MCP sprechen, können Sie sie über Hosts hinweg mischen und kombinieren, ohne etwas neu zu schreiben. Eine neue KI-App startet mit MCP-Support, und Ihre bestehenden Server sind darin von Tag eins an nutzbar.

Das ist das USB-C-Versprechen, für KI eingelöst: den Connector einmal bauen, überall einstecken.

Key Takeaways

Merken Sie sich die drei Rollen. Host (die KI-App, die der Nutzer anfasst), Client (der Verwalter je Verbindung im Host), Server (das Programm, das Tools, Resources und Prompts bereitstellt). Jedes MCP-Setup ist eine Anordnung dieser drei.
Fangen Sie mit einem Tool an, lokal. Schreiben Sie einen kleinen Server mit FastMCP, stellen Sie ein einzelnes, gut dokumentiertes Tool bereit, registrieren Sie es über stdio in der Konfiguration Ihres Hosts und bestätigen Sie, dass Claude es aufruft, bevor Sie mehr hinzufügen.
Schreiben Sie Docstrings für das Modell, nicht für Menschen. Die Tool-Beschreibung ist, was Claude liest, um zu entscheiden, wann es Ihr Tool aufruft. Vage Docstrings führen zu ausgelassenen oder falschen Tool-Calls.
Vergeben Sie Zugangsdaten nach dem Least-Privilege-Prinzip und lassen Sie Freigaben an. Ein Read-only-Token und Human-in-the-Loop-Bestätigung sind Ihre Hauptverteidigung, denn das Modell, nicht Sie, entscheidet, wann Tools feuern.
Denken Sie an die Schichtung. MCP ist der Standard-Port; das Agent SDK und Skills entscheiden, was Sie tun, sobald verbunden ist. Greifen Sie zur richtigen Schicht, statt Konnektivität selbst neu zu bauen. Starten Sie auf modelcontextprotocol.io.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

Write tool docstrings and type hints for the model's routing
Build MCP servers as local stdio, then flip transport to remote

Vollständiges Action Playbook ansehen →

MCP erklärt: das USB-C für KI-Tools