Das Wartungsproblem

Wir haben Tools, Skills und Connectors. Warum existiert dann MCP? Auf den ersten Blick sieht es aus wie eine zweite API, die auf der API aufgestapelt ist. Berechtigte Frage — und die Antwort hängt davon ab, wer den Integrationscode wartet.

Angenommen, Ihr Agent muss Aufgaben aus Asana abrufen, einen Google Calendar überprüfen und Slack durchsuchen — alles auf einmal. Mit benutzerdefinierten Tools müssen Sie drei Integrationen schreiben. Das ist machbar. Der schmerzhafte Teil kommt danach: Sie müssen diese Integrationen auch warten, jedes Mal wenn einer dieser Services seine API ändert, was häufig vorkommt. Glückwunsch, Sie warten jetzt einen Haufen von Third-Party-API-Wrappern.

MCP verlagert diese Wartung auf den Service-Provider. Asana veröffentlicht einen MCP-Server. Slack veröffentlicht einen. Google veröffentlicht einen. Jeder Server stellt seine eigenen Tools — mit Beschreibungen, Schemas und Authentifizierung — über ein standardisiertes Protokoll bereit. Wenn sich ihre API ändert, aktualisieren sie ihren Server. Sie ändern nichts.

Tools vs. Skills vs. MCP

Diese drei Features erfüllen unterschiedliche Aufgaben:

Tools verbinden Claude mit Ihren internen Systemen — Ihrer Datenbank, Ihrem Projekt-Tracker, Ihren proprietären APIs. Sie besitzen den Code, also besitzen Sie auch die Wartung.
Skills lehren Claude ein Verfahren — Ihre Report-Vorlage, Ihre Review-Checkliste. Skills sind Anweisungen, nicht unbedingt Integrationen.
MCP verbindet Claude mit Third-Party-Services, wo der Service-Provider die Integration wartet. Sie schreiben nicht den Asana-Wrapper — Asana hat das getan.

Die Kurzversion: Tools sind für Ihre Daten, Skills sind für Ihre Prozesse, und MCP ist für die Daten aller anderen.

Vergleichskarten für Tools, Skills und MCP, mit der MCP-Karte hervorgehoben: verbindet Claude mit Third-Party-Services, gewartet vom Service-Provider

Verbindung zu einem MCP-Server

Der sauberste Weg, um ein Gefühl für MCP zu bekommen, ist, Claude auf einen beliebigen MCP-Server zu verweisen und ihn das dort Vorhandene entdecken zu lassen. Für dieses Beispiel verwenden wir den Linear MCP-Server, mit den Verbindungsdetails und dem Auth-Token, die in einer . env-Datei gespeichert sind.

Zwei Teile arbeiten zusammen in der Anfrage. Der mcp_servers-Schlüssel deklariert die Verbindung — einen Typ, eine URL, einen Namen, um darauf zu verweisen, und optional ein Auth-Token. Dann konfiguriert ein Tool mit dem Typ mcp_toolset, welche Tools Claude von diesem Server verwenden kann. Die Standardeinstellung ist alle, aber wenn Sie es eingrenzen möchten, ist dies der Ort, um das zu tun.

import os import anthropic

client = anthropic. Anthropic()

response = client. beta. messages. create( model="claude-opus-4-8", max_tokens=1000, messages=[ {"role": "user", "content": "What tools do you have available? "} ], mcp_servers=[ { "type": "url", "url": "https://mcp. linear. app/mcp", "name": "linear", "authorization_token": os. environ["LINEAR_MCP_TOKEN"], } ], tools=[ { "type": "mcp_toolset", "mcp_server_name": "linear", } ], betas=["mcp-client-2025-11-20"], )

print(response)

Beachten Sie, dass wir nie ein einziges Tool-Schema geschrieben haben. Claude introspiziert den Server, erhält die Liste der Tools und ihrer Schemas zurück und wählt das richtige für den Prompt. Zum Zeitpunkt dieser Lektion ist der MCP-Connector in Beta — beachten Sie den Beta-Header in der Anfrage.

Führen Sie es aus, und wenn Ihre MCP-URL auf Linears MCP-Endpunkt verweist, listet Claude Linears Tools auf und ruft dann eines auf. Das Gleiche funktioniert für praktisch jeden konformen Server. Wir haben kein einziges Tool definiert. Wir haben keinen Linear-Client geschrieben. Linear wartet das.

Terminal-Ausgabe, die die entdeckten Tools des Linear MCP-Servers auflistet, gefolgt von Claude, der bemerkt, dass dies Linear-Projektmanagement-Tools sind und auswählt, welche aufgerufen werden sollen

Filtern, welche Tools Claude verwenden kann

MCP-Server stellen oft viele, viele Tools bereit — und Sie möchten nicht immer, dass Claude alle verwendet. Vielleicht möchten Sie nicht, dass es Schreibberechtigungen hat, oder Sie möchten einfach nicht, dass all diese Tool-Definitionen Kontext verbrauchen.

Die Lösung: Deaktivieren Sie standardmäßig alles, dann aktivieren Sie nur die spezifischen Tools, die Sie möchten. Hier ist dieses Muster mit einem Slack MCP-Server:

tools=[ { "type": "mcp_toolset", "mcp_server_name": "slack", "default_config": { "enabled": False, }, "configs": { "search_messages": {"enabled": True}, "list_channels": {"enabled": True}, }, } ]

Jetzt kann Claude Slack durchsuchen und Kanäle auflisten, aber es kann nicht posten oder löschen. Dies ist nützlich, wenn Sie einem Service für Lesevorgänge vertrauen, aber nicht möchten, dass Claude versehentlich in Ihrem Namen schreibt.

Zusammenfassung

MCP existiert, damit Sie Integrationen nicht warten müssen, die jemand anderes bereits erstellt hat. Der Service-Provider veröffentlicht einen MCP-Server und hält ihn aktuell — Sie ändern nichts, wenn sich ihre API ändert.
Wählen Sie das richtige Feature für die Aufgabe: Tools für Ihre Daten, Skills für Ihren Prozess, MCP für Third-Party-Services.
Deklarieren Sie die Verbindung in mcp_servers (Typ, URL, Name, optionales Auth-Token) und gewähren Sie Zugriff mit einem mcp_toolset-Eintrag in tools. Claude introspiziert den Server und entdeckt die Tools von selbst — keine Schemas zum Schreiben.
Grenzen Sie den Zugriff ein, indem Sie default_config: {"enabled": False} setzen und spezifische Tools in configs aktivieren — praktisch, um einen Server schreibgeschützt zu halten.
Der MCP-Connector ist derzeit in Beta, also fügen Sie den Beta-Header in Ihre Anfragen ein.
Besuchen Sie **modelcontextprotocol. io** für die Liste der verfügbaren Server und um mehr über das Protokoll zu erfahren.