Claude Code und MCP: von festen Tools zu erweiterbaren Faehigkeiten
Claude Code bringt einen festen Satz eingebauter Tools wie Read, Write und Bash mit. Ueber das Model Context Protocol kann es zur Laufzeit externe Prozesse anbinden und deren deklarierte Faehigkeiten als neue Tools nutzen, loest aber nicht die Frage der Wiederverwendbarkeit von Prozeduren.
TL;DR: Claude Code wird mit einem festen Satz eingebauter Tools wie Read, Write und Bash ausgeliefert. MCP, das Model Context Protocol, ermoeglicht es, zur Laufzeit eine Verbindung zu einem externen Prozess herzustellen und die von diesem Prozess deklarierten Faehigkeiten als neue Tools zu nutzen. MCP loest nicht die Frage, wie man eine Prozedur wiederverwendet. Das ist die Aufgabe eines Skills. MCP loest die Frage, wie das Modell eine Aktion ausfuehren kann, die nicht eingebaut war.
Stellen wir uns vor, dass Claude bevor es Code aendert, den aktuellen Stand eines Tickets in der internen Jira-Instanz Ihres Unternehmens pruefen soll.
Claude Code verfuegt nicht ueber ein Tool namens Jira. Es koennte Bash verwenden, um einen curl-Befehl zusammenzusetzen, ein API-Token, die Organisationsdomain und die Ticket-ID hinzuzufuegen, eine JSON-Anfrage zu bauen und dann die nuetzlichen Felder aus einer grossen Antwort herauszufiltern. Das kann funktionieren. Aber jedes Mal muss der Agent rekonstruieren, wo das Token liegt, wie der Endpunkt aussieht und wie die zurueckgegebenen Felder zu interpretieren sind.
Diese Art von Reibung ist bekannt. Eine fruehere, Skills gewidmete Diskussion beschrieb sie als das wiederholte Einfuegen einer Release-Checkliste. Hier ist der wiederholte Kontext keine Checkliste, sondern die Mechanik der Kommunikation mit einem externen System.
Eine naheliegende Reaktion lautet: Warum macht man diese curl-Schritte nicht zu einem Skill?
Das ist moeglich, aber der Skill wuerde operatives Wissen darueber buendeln, wie man mit Jira spricht. Die Aktionen, die Claude zur Verfuegung stehen, endeten weiterhin bei Bash. Ein Skill kann die Nutzung vorhandener Tools organisieren, er fuegt keinen neuen Ausfuehrungsmechanismus hinzu. Wenn die Jira-Integration Sitzungsstatus verwalten, mit Paginierung umgehen oder Schemata interpretieren muss, die sich je nach Berechtigungsstufe unterscheiden, ist das wiederholte Zusammensetzen und Parsen von Anfragen in Bash weniger zuverlaessig als der Aufruf einer eigens entwickelten Aktion, die Jira bereits versteht.
Was fehlt, ist nicht ein weiterer Satz Anweisungen. Es ist eine neue Aktion: etwas mit einem Namen, Parametern und einem Ergebnis, das das Modell direkt aufrufen kann, wie Read oder Bash. Eingebaute Tools sind Teil von Claude Code selbst. Man kann nicht einfach den Code des Produkts aendern, damit es Jira erkennt.
Genau diese Ebene adressiert MCP: Wie kann ein Modell zur Laufzeit eine neue Aktion erhalten, ohne Claude Code selbst zu veraendern?
Ein Skill ist ein Ordner mit Markdown- und Unterstuetzungsdateien, den Claude liest und entfaltet. Ein MCP-Server ist etwas anderes: Es ist ein unabhaengig laufender Prozess oder Dienst.
Er kann ein lokales Programm sein, das auf ein Dateisystem zugreifen kann, oder ein langlaufender Server innerhalb eines Firmennetzwerks. Er deklariert, dass er bestimmte Tools, lesbare Daten und wiederverwendbare Prompt-Vorlagen anbietet. Das Protokoll verleiht dieser Deklaration eine gemeinsame Form, unabhaengig von der Sprache, in der der Server gebaut wurde, oder der Maschine, auf der er laeuft.
Diese Artikelserie wird diesen Prozess MCP-Server nennen.
Auf der anderen Seite agiert Claude Code als MCP-Client. Er verbindet sich mit einem Server, fragt, was dieser Server kann, und uebersetzt die Antwort in eine Form, die Claude Code verwenden kann. Aus Nutzersicht ist die groessere Anwendung der Host: Sie kann mehrere MCP-Clients und mehrere Server gleichzeitig verwalten.
Diese Bezeichnungen, Host, Client und Server, sind allgemeine Terminologie des Model Context Protocol und keine Konzepte, die ausschliesslich fuer Claude Code erfunden wurden. Denselben Wortschatz verwendet man, wenn eine IDE oder ein anderer Desktop-Assistent MCP unterstuetzt. Die MCP-Einfuehrung beschreibt das Protokoll als einen offenen Standard zur Verbindung von KI-Anwendungen mit externen Systemen.
Ein MCP-Server kann mehr als eine Art von Faehigkeit deklarieren. Fuer diese Serie sind drei Kategorien relevant:
Der Anschluss eines Servers bedeutet nicht, dass alle drei Kategorien vorhanden sind. Ein Server kann nur Tools, nur Ressourcen oder eine Kombination daraus anbieten. Der Client muss zunaechst herausfinden, was der Server unterstuetzt. Einen praktischen Ueberblick darueber, mit welchen Arten externer Systeme sich Claude Code verbinden kann, bietet die offizielle Claude-Code-MCP-Dokumentation.
Der wichtige Punkt an dieser Stelle ist einfach: Tools, Ressourcen und Prompts sind drei verschiedene Dinge.
Angenommen, ein MCP-Server deklariert ein Tool namens create_issue. Claude sieht es nicht als eine besondere externe Faehigkeit. Claude Code benennt es und verpackt es so, dass es zu einem weiteren Eintrag in der normalen Tool-Liste wird, neben Read und Bash.
Diese Einheitlichkeit ist die Designentscheidung, die MCP nuetzlich macht. Das Modell muss nicht in einen eigenen MCP-Modus schalten, bevor es entscheidet, ob es ein Tool aufruft. Die Quelle mag extern sein, aber die Form, die der Agent sieht, bleibt ein Tool-Name, eine Beschreibung, ein Eingabeschema und ein Ergebnis.
Der vorangegangene Artikel dieser Serie zeichnet den vollstaendigen Weg von der Serverkonfiguration bis zu einem aufrufbaren Tool nach. Der Rest der Serie wird die wichtigsten Fragen entlang dieses Wegs aufschluesseln:
Der Umweg ueber die Frage, ob dies ein Skill sein sollte, ist keine Abschweifung. Es lohnt sich, die Grenze gleich zu Beginn zu ziehen, weil jeder spaetere Artikel auf ihr aufbaut.
Die beiden Mechanismen ergaenzen sich. Sobald ein MCP-Server ein nuetzliches Tool bereitstellt, kann ein Skill dieses Tool durchaus in einen wiederholbaren Workflow einbinden. Die eine Ebene legt fest, wie vorzugehen ist; die andere veraendert, welche Aktionen ueberhaupt zur Verfuegung stehen.
Eine kompakte Merkhilfe fuer den Unterschied lautet:
Skills beantworten die Frage, wie man etwas tut. MCP beantwortet die Frage, was man tun kann.
Diese Rahmung verdeutlicht auch, warum MCP nicht als Sammlung von Prompt-Schnipseln oder Shell-Rezepten behandelt werden sollte. Es ist eine Protokollgrenze, die es unabhaengig entwickelten Faehigkeiten ermoeglicht, in einen Agenten zu gelangen, ohne dass der Agent selbst zu einer Sammlung von Sonderfaellen wird.
Bevor sich Claude Code mit einem MCP-Server verbinden kann, muss dieser Server in der Konfiguration auftauchen. Derselbe Name kann in einem Projekt, in einer Konfiguration auf Nutzer-Ebene oder in zentral verwalteten Einstellungen definiert sein. Was geschieht, wenn diese Quellen uneins sind?
Der naechste Artikel geht diesen Weg: vom ersten Konfigurationseintrag ueber Scope und Vorrangregeln bis zu einem abgeschlossenen Handshake und einem Client, der weiss, welche Faehigkeiten der Server unterstuetzt.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
TL;DR: Claude Code ships with a fixed set of built-in tools such as Read, Write, and Bash. MCP—the Model Context Protocol—lets it connect to an external process at runtime and use that process’s declared capabilities as new tools. MCP does not solve “how should I reuse a procedure?” That is the job of a Skill. MCP solves “how can the model perform an action it did not ship with?”
Imagine that, before changing code, you want Claude to check the current state of an issue in your company’s internal Jira instance.
Claude Code does not come with a tool named Jira. It could use Bash to assemble a curl command, add an API token, organization domain, and issue ID, build a JSON request, then sift the useful fields from a large response. That can work. But every time, the agent has to reconstruct where the token lives, what the endpoint looks like, and how to interpret the returned fields.
That is a familiar kind of friction. An earlier Skill-focused discussion described it as repeatedly pasting a release checklist. Here, the repeated context is not a checklist but the mechanics of talking to an external system.
A natural reaction is: why not turn those curl steps into a Skill?
You can—but the Skill would package operational knowledge about how to talk to Jira. The actions available to Claude would still end at Bash. A Skill can organize the use of existing tools; it does not add a new executor. If the Jira integration needs to maintain session state, deal with pagination, or interpret schemas that differ by permission level, repeatedly composing requests and parsing them in Bash is less dependable than calling a purpose-built action that already understands Jira.
What is missing is not another set of instructions. It is a new action: something with a name, parameters, and a result, which the model can invoke directly like Read or Bash. Built-in tools are part of Claude Code itself. You cannot edit the product’s code just to make it recognize Jira.
That is the layer MCP addresses: how can a model gain a new action at runtime without changing Claude Code itself?
A Skill is a folder containing Markdown and supporting files. Claude reads and expands it. An MCP server is different: it is an independently running process or service.
It might be a local program that can access a filesystem, or a long-running server inside a company network. It declares that it offers particular tools, readable data, and reusable prompt templates. The protocol gives that declaration a common shape regardless of the language used to build the server or the machine on which it runs.
This series will call that process an MCP server.
On the other side, Claude Code acts as an MCP client. It connects to a server, asks what that server can do, and adapts the answer into a form Claude Code can use. From the user’s perspective, the larger application is the host: it can manage several MCP clients and several servers at once.
Those names—host, client, and server—are general Model Context Protocol terminology, not concepts invented solely for Claude Code. The same vocabulary applies when an IDE or another desktop assistant supports MCP. The MCP introduction describes the protocol as an open standard for connecting AI applications with external systems.
An MCP server can declare more than one kind of capability. Three categories matter for this series:
Connecting one server does not imply that all three categories exist. A server may expose only tools, only resources, or some combination. The client first needs to learn what the server supports. For a practical overview of the kinds of external systems Claude Code can connect to, see the official Claude Code MCP documentation.
The important point for now is simple: tools, resources, and prompts are three different things.
Suppose an MCP server declares a create_issue tool. Claude does not see it as a special “external capability.” Claude Code names and wraps it so it becomes another entry in the normal tool list, alongside Read and Bash.
That uniformity is the design decision that makes MCP useful. The model need not switch into a separate “MCP mode” before deciding whether to call a tool. The source may be external, but the agent-facing shape remains a tool name, description, input schema, and result.
The previous article in this series maps the full route from server configuration to a callable tool. The rest of the series will unpack the main questions along that route:
The detour through “should this be a Skill?” is not a distraction. It is worth establishing the boundary at the start because every later article relies on it.
The two mechanisms are complementary. Once an MCP server adds a useful tool, a Skill can absolutely include that tool in a repeatable workflow. One layer defines how to proceed; the other changes what actions are available at all.
A compact way to remember the distinction is:
Skills answer “how do I do this?” MCP answers “what can I do?”
That framing also clarifies why MCP should not be treated as a bag of prompt snippets or shell recipes. It is a protocol boundary that lets independently built capabilities enter an agent without turning the agent itself into a collection of special cases.
Before Claude Code can connect to an MCP server, that server must appear in configuration. The same name might be defined in a project, a user-level configuration, or centrally managed settings. What happens when those sources disagree?
The next article follows that path: from the first configuration entry, through scope and precedence, to a completed handshake and a client that knows which capabilities the server supports.