MCP, CLI und Skills zusammen: Eine Verbindungsstack für Produktionsagenten

Demos prägten das Jahr 2024, Coding-Agents das Jahr 2025 – 2026 wird das Jahr sein, in dem allgemeinwissensbasierte Arbeitsagenten in die Produktion gehen. Berichten zufolge hat das Model Context Protocol bereits etwa 110 Millionen monatliche Downloads erreicht, ein Meilenstein, den es schneller erreichte als React. Doch da die Agenten Unternehmensworkflows übernehmen, die mehrere SaaS-Apps und gemeinsame Speicherorte umfassen, taucht immer wieder ein Punkt auf: Verbindbarkeit ist keine Einzelheit. Jeder, der behauptet, es gäbe eine einzige Lösung – sei es die Computernutzung, MCP oder die Kommandozeile – übertreibt. Starke Agenten wählen keine einzige Methode aus; sie nutzen stattdessen den gesamten Verbindbarkeitsstack gleichzeitig.

Drei Ebenen

Fähigkeiten, die CLI und MCP lösen jeweils ein anderes Problem und sind außerdem unterschiedlich aufgebaut.

• Fähigkeiten beinhalten Fachwissen. Es handelt sich dabei um wiederverwendbare Prozeduranweisungen, meist Markdown-Dateien, die einem Modell beibringen, wie es Tools nutzen kann. Sie werden zwischen Clients ausgetauscht und liefern den Kontext, den komplexe Aufgaben benötigen. Sie werden entweder von Menschen geschrieben oder von Agenten generiert und werden aus lokalen Verzeichnissen wie .claude/skills/ oder aus entfernten Repositorien geladen.
• CLI, also die Nutzung eines Computers, bedeutet eine lokale Ausführung im Unix-Stil. Sie lässt sich gut kombinieren, verbraucht nur wenige Token (etwa 200 pro Antwort) und profitiert vom Vortraining des Modells mit Tools wie git, gh und curl. CLI-Tools erhält man durch das Installieren gewöhnlicher Binärdateien über einen Paketmanager.

MCP ist das Verbindungsorgan. Es bietet umfangreiche Semantik, Plattformunabhängigkeit sowie Unternehmensfunktionen wie OAuth, Verwaltungspolitiken und Audit-Spuren. Ein Server wird in Code definiert, beispielsweise server.py oder server.ts, zusammen mit Tools, Ressourcen und Anweisungen, und kommuniziert über HTTP oder SSE per JSON-RPC 2.0.

Wann MCP die richtige Wahl ist

Wählen Sie MCP, wenn Sie umfangreiche Semantik, Autorisierung sowie Unabhängigkeit von der Plattform benötigen. Es verfolgt einen auf Schemata ausgerichteten, deterministischen Ansatz bei der Auswahl von Tools, wobei Verwaltungsfunktionen und Audit-Spuren bereits integriert sind. Der Nachteil liegt im Kontext: Eine naive Einrichtung, die alle Tool-Schemata im Voraus lädt, kann 44.000 bis 55.000 Tokens verbrauchen, und jede Antwort ist ein vollständiges, typisiertes JSON-Objekt, das zwar gut für programmierte Auswertungen geeignet ist, aber viele Tokens benötigt.

Für alle, die Server programmieren, gilt der Rat, beschreibende Funktionen- und Parameternamen zu verwenden sowie jeden Parameter mit einer Beschreibung zu annotieren. Modelle arbeiten besser und schneller, wenn sie genau wissen, was von ihnen erwartet wird.

# Annotated Tool Definitions
from typing import Annotated
from datetime import date
from enum import Enum

class Category(str, Enum):
    TRAVEL = "travel"
    MEALS = "meals"
    OFFICE = "office"

def submit_expense(
    amount: Annotated[float, "The expense amount in USD"],
    date: Annotated[date, "Date of the expense in YYYY-MM-DD format"],
    category: Annotated[Category, "The expense category"]
) -> str:
    """Submits a new expense report for approval."""
    pass

Wann die CLI die richtige Wahl ist

Falls das Tool bereits in den Vortrainingsdaten des Modells vorhanden ist, wie bei Git oder der GitHub CLI, ist die Ausführung über die Kommandozeile äußerst vorteilhaft. Das Modell kann Befehle mithilfe von Pipes und Umleitungen verknüpfen und Fehler kostengünstig verarbeiten. Anstatt einen riesigen JSON-Datensatz zu erhalten, kann es mit jq filtern und nur das zurückbekommen, was es benötigt – eine kompakte Antwort von etwa 200 Tokens.

Progressive Entdeckung

Die größte Verbesserung bei den meisten Agentenlösungen ist die progressive Entdeckung. Anstatt alle Tools in das Kontextfenster zu laden, sollte die Ladung auf den Zeitpunkt verschoben werden, an dem das Modell tatsächlich eines benötigt. Geben Sie ihm die Fähigkeit tool_search, damit es Tools dynamisch suchen kann – dadurch kann der Kontextverbrauch um das Fünffache reduziert werden.

Programmatische Aufrufung von Tools

Wenn ein Modell mehrere Tools koordinieren muss, sollte es diese nicht nacheinander aufrufen, da bei jedem Schritt eine Latenz durch die Inferenz entsteht. Verwenden Sie eine programmatische Tool-Aufrufmethode, auch Code Mode genannt. Bieten Sie einen REPL wie ein V8-Isolat oder einen Python-Sandbox an und lassen Sie das Modell ein Skript schreiben, das die Tools zusammenführt. Das Skript wird nur einmal geschrieben und führt die gesamte Abfolge aus, wodurch die Latenz erheblich reduziert wird.

// Programmatic Tool Calling (Code Mode)
// Instead of multiple sequential LLM turns, the model writes this script once:
const issue = await mcp.call_tool("linear_get_issue", { id: "ENG-5121" });
const prs = await mcp.call_tool("github_list_prs", { repo: "frontend" });

// Use structured output to enforce types
const expectedType = z.object({ title: z.string(), status: z.string() }).passthrough();
const typedIssue = await extract("claude-haiku-4-5", expectedType, issue);py

Entwicklung für Agenten

Serverentwickler sollten aufhören, REST-APIs eins-zu-eins auf MCP-Server abzubilden, und von Anfang an für Agenten entwickeln. Drei Gewohnheiten helfen dabei. Entwickeln Sie Tools mit klarer Absicht, genauso wie eine Benutzeroberfläche für Menschen. Stellen Sie Ausführungsumgebungen bereit, wie es Cloudflare MCP tut, damit ein Modell komplexe Workflows in Code orchestrieren kann. Und veröffentlichen Sie eine MCP-App: Nutzen Sie die Semantik von MCP, um UI-Ressourcen wie HTML, JavaScript und CSS über das Netzwerk zu übertragen, sodass der Server seine eigene Benutzeroberfläche im Client darstellen kann.

Was kommt für MCP

Das Ökosystem entwickelt sich schnell, um den Anforderungen von Unternehmen gerecht zu werden und Skalierbarkeit zu gewährleisten. Der Roadmap für 2026 umfasst drei Schwerpunkte.

• Ein besseres Kernkonzept: Ein neuer, zustandsloser Transportmechanismus, der von Google vorgeschlagen wurde, sollte es ermöglichen, MCP-Server einfacher auf Kubernetes und Cloud Run zu deployen. Zudem sind Version 2.0 der TypeScript- und Python-SDKs erwartet.
• Integration überall: Cross-App Access würde ein einheitliches Anmelden auf allen MCP-Servern über den Identitätsanbieter des Unternehmens ermöglichen, und die Server könnten automatisch aus einer Datei unter .well-known/mcp-server-card/server.json gefunden werden.
• Jenseits des aktuellen Standes: Skills über MCP würden es Servern ermöglichen, ihr Domänenwissen zusammen mit ihren Tools über die Endpunkte skills/list und skills/get bereitzustellen.

Wahlmöglichkeiten

Die Entscheidung hängt vom Kontext und den Anforderungen ab: MCP, wenn Governance und umfangreiche Semantik erforderlich sind, CLI, wenn das Modell bereits das Tool kennt und Tokens wichtig sind, sowie Skills, um das prozedurale Wissen bereitzustellen, das alles miteinander verbindet.

Zusammenfassung

Kein einzelnes Tool ist überlegen, und es ist irreführend, es als Konkurrenz zwischen MCP und CLI darzustellen. Produktionsagenten benötigen mehrere Schichten. Kritik an MCP – insbesondere hinsichtlich des Token-Overheads, Lücken in der Authentifizierung sowie ungleicher Serverqualität – weist auf echte Probleme hin, doch es handelt sich dabei um ingenieurtechnische Probleme mit Lösungen, und das Ökosystem passt sich bereits an. Progressive Discovery und Code Mode verringern den Token-Overhead sowie die Latenz, sodass der Standard angepasst statt aufgegeben werden kann. Der Verzicht auf MCP in einem Unternehmen ersetzt diese Probleme durch schlimmere: fragmentierte Authentifizierung, fehlende Audit-Spuren sowie Vendor-Lock-in. Man kann erwarten, dass die leistungsstärksten Agenten Skills für Wissensverarbeitung, MCP für regulierte Verbindungen und die CLI für kostengünstige lokale Ausführung nutzen.