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

Vor USB-C hatte jedes Gerät sein eigenes Ladekabel, und zwei Dinge zu verbinden hieß, den passenden Dongle zu suchen. Das Model Context ProtocolModel Context ProtocolEin offener Standard, mit dem KI-Assistenten einheitlich und kontrolliert an die Werkzeuge und Daten des Unternehmens angebunden werden, statt jede Integration einzeln zu bauen.Vollständige Definition ansehen → (MCP) tut für KI-Tools, was USB-C für Kabel getan hat: es definiert einen offenen Standard, sodass jede KI-App mit jedem Tool über eine einzige, vorhersehbare Schnittstelle sprechen kann.

Das ist relevant, weil Sie die Alternative schon kennen. Jedes Mal, wenn Sie Claude mit eigenem Glue Code an eine neue Datenquelle hängen, bauen Sie eine Einzelintegration, die nur Sie pflegen. MCP ersetzt diesen Wildwuchs durch einen gemeinsamen Vertrag. Bauen Sie 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 Teile: Host, Client, Server

MCP hat genau drei Rollen. Sobald Sie sie benennen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen, fügt sich jede Integration, über die 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 auch. Ebenso die Claude Web- und Mobile-App, wenn Sie einen Connector hinzufügen. Der Host besitzt die Konversation, betreibt das Modell und entscheidet, welche Tools das Modell erreichen darf.

Denken Sie beim Host an den Laptop. ErErDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → ist das Ding mit dem USB-C-Port.

Der Client

Der Client ist ein kleiner Connector, der innerhalb des Hosts 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 saubere, isolierten Kanal offen halten.

Sie fassen den Client selten direkt an. Er ist Infrastruktur, die der Host für Sie verwaltet. Denken Sie an den USB-C-Controller-Chip: unsichtbar, aber er setzt das Protokoll auf der 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, Ressourcen, die er lesen kann, und Prompts, die er verwenden kann. Sie schreiben Server (oder installieren solche, die andere geschrieben haben), um Claude mit Ihren realen 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 derselbe. Der Host startet einen Client. Der Client verbindet sich mit einem Server. Der Server gibt bekannt, was er kann. Das Modell, das im Host läuft, entscheidet, wann diese Fähigkeiten aufgerufen werden, 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, sie aufzurufen.
• Resources: Daten, die der Host lesen kann, etwa eine bestimmte Wiki-Seite oder eine Datei. Denken Sie an Read-only-Kontext, den Nutzer oder Modell hereinziehen.
• 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, werden stark auf Tools setzen. Dort liegt der Nutzen.

Ein konkretes Beispiel: Ihr Team-Wiki für Claude zugänglich machen

Angenommen, Ihr Team betreibt ein internes Wiki. Die Engineers vergessen ständig, wo das On-Call-Runbook liegt, und Sie wollen, dass Claude auf "wie lautet unsere Deploy-Rollback-Prozedur?" antwortet, 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.

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 gewöhnliche 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-SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen →, gegen das der Client validiert.

Achten Sie darauf, was Sie nicht getan haben. Sie haben nichts Claude-Spezifisches geschrieben. Sie haben den Output des Modells nicht geparst und kein Tool-Call-JSON von Hand formatiert. Das Protokoll erledigt all das. Wenn Ihr Kollege nächstes Jahr einen anderen MCP-Host nutzt, funktioniert genau dieser Server weiter.

Anbindung an Claude Desktop

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

{
  "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 weiter, Ihr Server fragt das Wiki ab, und die Snippets fließen als fundierter Kontext zurück in die Konversation.

Das ist dasselbe Muster hinter den Connectors, die Sie in den Claude Apps und im Connector-Marketplace sehen: vorgefertigte MCP-Server für gängige Tools (Google Drive, GitHub und weitere), die Sie mit einem Klick aktivieren statt eine Config-Datei zu bearbeiten. Unter der Haube sind ein Marketplace-Connector und Ihr selbstgebauter Wiki-Server dieselbe Art von Sache.

Transports: lokal vs. remote

Wie spricht der Client eigentlich mit dem Server? MCP definiert zwei zentrale Transports, den Kanal, über den die Nachrichten laufen.

• stdio: der Host startet den Server als lokalen Subprozess und spricht über Standard-Input/Output mit ihm. Das nutzt die Config oben. Gut für lokale Tools und die Entwicklung.
• Streamable HTTP: der Server läuft als remote Web-Service 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 dem 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 die Hosts aller Beteiligten auf die URL.

Wo MCP im größeren 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 dem Bau autonomer Agenten im Code. Wenn dieser Agent externe Systeme anfassen muss, nutzt er MCP-Server als seine Tools. MCP ist also kein Konkurrent zum Agent SDK, es ist der Standard, über den das SDK sich mit der Welt verbindet. 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 Ebene. Ein Skill bündelt Anweisungen, 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 zu erledigen ist). Ein gut durchdachtes Setup nutzt oft beides: ein Skill, der Ihren Incident-Response-Prozess beschreibt und dabei MCP-Tools aufruft, die Ihre Monitoring-Dashboards lesen.

Die Messages API ist die Low-Level-Oberfläche. Wenn Sie Ihren eigenen Host von Grund auf bauen, behandeln Sie dort die Modellaufrufe und verdrahten MCP in Ihrer eigenen 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 APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen →, das Agent SDK und Connectors im Detail, und auf github.com/anthropics liegen die SDKs und Referenzserver.

Das Denkmodell: MCP standardisiert den *Port*, das Agent SDK und Skills entscheiden, *was Sie nach dem Verbinden tun*, 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 zerstörerische Aktionen ausführen. Behandeln Sie einen MCP-Server von Dritten wie jede andere Dependency, die Sie auditieren würden.
2. Begrenzen Sie Server-Berechtigungen strikt. Ihr Wiki-Server sollte ein Read-only-API-TokenTokenEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen → 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 Bestätigung. Deaktivieren Sie das nicht für etwas, 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 beliebig kombinieren, ohne etwas neu zu schreiben. Eine neue KI-App startet mit MCP-Support, und Ihre bestehenden Server sind darin ab Tag eins aktiv.

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

Key Takeaways

• Merken Sie sich die drei Rollen. Host (die KI-App, die der Nutzer anfasst), Client (der Verbindungsmanager pro 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 lokal an. Schreiben Sie einen kleinen Server mit FastMCP, stellen Sie ein einzelnes, gut dokumentiertes Tool bereit, registrieren Sie es per stdio in der Config 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-Aufrufen.
• Vergeben Sie Zugangsdaten nach Least Privilege und lassen Sie Bestätigungen an. Ein Read-only-Token und Human-in-the-Loop-Bestätigung sind Ihre Hauptverteidigung, denn das Modell entscheidet, wann Tools feuern, nicht Sie.
• Behalten Sie die Schichtung im Kopf. MCP ist der Standard-Port; das Agent SDK und Skills entscheiden, was Sie nach dem Verbinden tun. Greifen Sie zur richtigen Ebene, statt Konnektivität selbst neu zu bauen. Fangen Sie bei modelcontextprotocol.io an.