MCP, Skills, Tools, Subagents: Was unterscheidet sie — und was ändert sich am KI-Agenten-Stack 2026?

Kurzfassung: Tools, MCP, Skills und Subagents sind keine vier austauschbaren Produktnamen — sie sind vier unterschiedliche Schichten im Agent-Stack 2026. Tools sind die aufrufbaren Verträge, die das Modell sieht (Name + JSON Schema). MCP ist das Protokoll zur Entdeckung und zum Aufruf zwischen Host und externen Tool-Prozessen. Skills sind bedarfsweise geladene Verfahrens-Playbooks (wie die Arbeit erledigt wird). Subagents sind delegierte Agenten mit eigenem Kontext. Wer sie zu einem Buzzword zusammenwirft, debuggt die falsche Schicht.

Stand 11. September 2026. Wir haben bereits behandelt, was MCP ist, den Agent-JSON-Datenfluss und JSON Schema als Vertrag. Dieser Text beantwortet nur: was jede Schicht besitzt, wie sie gestapelt werden und wohin der Stack 2026 konvergiert.

Vier Schichten auf einen Blick

Wenn Leute sagen „dem Agenten ein Tool hinzufügen“, meinen sie oft vier verschiedene Dinge. Ordnen Sie den Satz dieser Tabelle zu:

Ein Satz: Tools sind „was aufrufbar ist“; MCP ist „woher Tools kommen“; Skills sind „wie diese Arbeit erledigt wird“; Subagents sind „wer es macht, in welchem Kontext“. JSON Schema durchzieht Tools und MCP; Skills und Subagents steuern vor allem Prompts, Policy und Sitzungsgrenzen.

Tools: der Aufrufvertrag vor dem Modell

Ein Tool (oder Function) ist die kleinste aufrufbare Einheit, die das Modell sieht. Anbieternamen unterscheiden sich — OpenAI Tools / Function Calling, Anthropic Tool Use, Gemini Function Declarations — die Form ist gleich: Sie deklarieren Tools; das Modell liefert strukturierte tool_calls; der Host führt sie aus und schreibt Ergebnisse zurück in den Chat.

Eine Tool-Definition sieht üblicherweise so aus:

{
  "type": "function",
  "function": {
    "name": "validate_json",
    "description": "Validate JSON text and return parse errors.",
    "parameters": {
      "type": "object",
      "properties": {
        "text": { "type": "string" }
      },
      "required": ["text"],
      "additionalProperties": false
    }
  }
}

Was Verhalten wirklich bindet, ist JSON Schema: Feldnamen, Typen, required, additionalProperties. Modelle können wechseln; das Schema sollte nicht mit ihnen driften. Siehe warum Tool Calling von JSON Schema abhängt für die Validierungsdisziplin. Hier gilt nur: eine natürlichsprachliche Tool-Beschreibung ohne Schema ist 2026 kein Produktionsvertrag mehr.

Die Grenze der Tools-Schicht ist scharf: sie entscheidet nicht, ob die Implementierung im Prozess oder remote läuft, und sie entscheidet nicht, wie mehrstufige Arbeit zerlegt wird. Das gehört zu MCP und zu Skills / Subagents.

MCP: die prozessübergreifende Tool-Buchse

MCP (Model Context Protocol) beantwortet, wie Tools und Kontext außerhalb des Host-Prozesses entdeckt und aufgerufen werden. Nachrichten sind JSON-RPC 2.0; gängige Methoden sind tools/list, tools/call sowie Resources / Prompts. Ein MCP Client im Host (Cursor, VS Code, Claude Desktop, …) verbindet sich mit einem MCP Server und übersetzt exponierte Tools in das Tools-Array, das das Modell versteht.

Der korrekte Stack ist:

1. Der MCP Server beschreibt jedes Tool mit inputSchema (weiterhin JSON Schema);
2. Der Host ruft tools/list auf und mappt auf Modell-Tool-Deklarationen;
3. Das Modell emittiert tool_calls;
4. Der Host sendet tools/call an den Server und schreibt result zurück in den Dialog.

MCP als „weiteres Function Calling“ zu bezeichnen, ist der häufigste Fehlschluss 2025–2026. Function Calling sitzt an der Modell-API-Grenze; MCP an der Grenze Host ↔ Server. Die aktuelle Spezifikation ist 2026-07-28: kein Session-Handshake; Anfragen tragen _meta. Details: MCP-Leitfaden und Migrationsleitfaden.

Wann Sie MCP nicht brauchen: ein Prozess, Tools fest im Host verdrahtet, keine app-übergreifende Wiederverwendung — Tool Calling allein reicht. Wann doch: denselben Server über IDEs / Desktops wiederverwenden, Prozessisolation, dynamische Tool-Entdeckung.

Skills: wiederverwendbare How-to-Playbooks

Ein Skill ist kein weiteres Tool — es ist prozedurales Wissen, das der Agent bei Bedarf laden kann: wann aktivieren, welche Schritte, was prüfen, welche Tools erlaubt sind. In der Praxis oft eine Repo-SKILL.md (oder ein äquivalentes Regelpaket): Titel, Trigger, Checkliste, Verbote, zugehörige Skriptpfade.

Gegenüber Tools / MCP:

2026 behandeln IDE-Agenten Skills als First-Class: kurze Aufgaben nutzen Built-ins; lange Abläufe, Teamnormen und Ops-Playbooks leben in Skills, damit Sie nicht jedes Mal das ganze Handbuch in den System-Prompt kleben. Ein Skill kann steuern, welche Tools aufgerufen werden, und Gates wie „JSON vor dem Submit validieren“ durchsetzen — ist aber üblicherweise keine JSON-RPC-Methode.

Häufige Verwechslung: ein verpacktes Shell-Skript, das sowohl Skill als auch Tool heißt. Faustregel — wenn das Modell es einmal per Schema aufruft und ein strukturiertes Ergebnis bekommt, ist es ein Tool; wenn ein Dokument dem Agenten sagt „folge diesen fünf Schritten, rufe bei Bedarf Tools auf“, ist es ein Skill.

Subagents: Delegation mit isoliertem Kontext

Ein Subagent ist eine Kind-Sitzung, an die der Eltern-Agent delegiert: meist eigenes Kontextfenster, engerer System-Prompt, strengere Tool-Allowlist und eine Zusammenfassung zurück an den Eltern. Er fügt nicht „noch eine Funktion“ hinzu; er bekämpft Kontextverschmutzung und ermöglicht parallele Exploration.

Typische Einsätze:

• Isolierte Recherche — das Kind wühlt durch Repo oder Logs; der Eltern behält nur die Schlussfolgerung.
• Parallele Arbeit — Frontend-Änderungen, Tests und Textübersetzung laufen ohne Kampf um einen Kontext.
• Enge Rollen — Security-Review, Code-Exploration, CI-Diagnose bekommen jeweils eigenen Prompt und eigene Tools.

In der Praxis wird ein Subagent oft dem Eltern als besonderes Tool exponiert (z. B. Task / spawn_agent): Argumente sind Aufgabenbeschreibung und Typ; die Rückgabe ist die finale Antwort des Kindes. Das heißt nicht Subagent = Tool. Das Tool ist die Aufruffläche; der Subagent ist eine weitere zustandsbehaftete Reasoning-Schleife.

Gegenüber Skills: ein Skill sagt „wie“; ein Subagent entscheidet „öffne eine andere Sitzung dafür“. Ein Skill kann fordern „komplexe Triage muss den CI-Subagent starten“; dieser Subagent lädt dann eigene Skills und Tools.

Wie die vier Schichten gestapelt werden

Eine reale Aufgabe nutzt oft alle vier. Beispiel: „Blogpost schreiben und deployen“ (illustrativ, nicht das private Protokoll dieser Seite):

1. Der Eltern lädt einen Skill — „Blog-Publish-Checkliste“: Body, Locales, Sitemap, IndexNow.
2. Der Eltern ruft einen Subagent auf, um historische Artikel-Templates zu erkunden, damit Dutzende HTML-Dateien nie in den Hauptkontext gelangen.
3. Die Hauptsitzung bearbeitet das Frontend über Tools (Dateien lesen/schreiben, Shell); liegen Tools außerprozess, laufen Entdeckung und Aufrufe über MCP.
4. Wo strukturierte Parameter auftauchen, hält JSON Schema die Felder fest — besonders für alles, was die Maschine verlässt.

Datenfluss in einer Zeile:

User → Host / parent agent
      → Skills (pick the workflow)
      → Subagents (optional delegation)
      → Tool declarations (for the model)
      → optional MCP Client ↔ MCP Server
      → results written back into the dialogue

Debug-Spickzettel: Modell ruft das falsche Tool → Tools / Schema; Tool-Prozess verbindet nicht → MCP; Schritte werden übersprungen → Skill; Kontext explodiert oder kontaminiert → Subagent.

Was sich im Agent-Stack 2026 ändert

Verglichen mit 2024s „Funktionen in den Prompt stopfen“ verdichtet sich 2026 auf fünf Verschiebungen:

Ein weiterer Strang ist die Verschmelzung strukturierter Ausgaben mit Tool-Argumenten: Business-JSON, Tool-Arguments und MCP inputSchema teilen dieselbe Schema-Disziplin. Siehe was Structured Output ist und den OpenAI-vs-Gemini-Vergleich.

Produktseitig sind IDE-Agenten nicht mehr nur „Chat + Autocomplete“: der Default-Stack umfasst Tool Calling, MCP-Connectoren, ein Skills-Verzeichnis und spawnbare Subagents. Für Builder heißt das: Sie liefern mehr als eine API — entdeckbare Tools (MCP/Tools) + befolgbare Workflows (Skills) + Rollen, die bei Bedarf delegierbar sind (Subagents).

Was Sie jetzt wählen und schreiben sollten

• Schreiben Sie das Schema, bevor Sie das Tool exponieren. Setzen Sie additionalProperties: false, füllen Sie required; validieren Sie Beispiel-Arguments im Browser mit den Tools dieser Seite.
• Packen Sie einen MCP Server nur, wenn Tools app-übergreifend wiederverwendet werden müssen. Ein einzelnes Skript in einem Host braucht kein MCP.
• Kodieren Sie wiederholte Team-Workflows als Skills. Publish, Migration, Triage, Security-Review — sind die Schritte stabil, hören Sie auf, sich auf „dem Modell erinnern“ zu verlassen.
• Teilen Sie einen Subagent ab, wenn der Kontext lang wird. Explorative, read-only, hoch-rauschende Arbeit bevorzugt delegieren; Entscheidungen und finale Patches beim Eltern lassen.
• Ersetzen Sie Schema nicht durch einen Skill, und MCP nicht durch einen Subagent. Prozess ≠ Vertrag ≠ Transport. Vermischung erzeugt „die Doku sagt validieren“, während Produktion den Check nie ausführt.

Für lokale JSON-Checks speichern Sie inputSchema, Modell-Argument-Samples und MCP-tools/call-Ergebnis-Samples und nutzen den JSON-Validator und JSON Diff. Nichts verlässt den Browser — derselbe on-device-first Privacy-Impuls.

FAQ

Fazit

Tools definieren, was das Modell aufrufen kann; MCP definiert, wie Tools aus externen Prozessen entdeckt und aufgerufen werden; Skills definieren, wie Arbeit nach Vorschrift erledigt wird; Subagents definieren, wie Kontext isoliert und delegiert wird. Der Agent-Stack 2026 konvergiert von „eine Chatbox + Ad-hoc-Funktionen“ zu diesen vier Schichten plus einem JSON-Schema-Vertragsgürtel.

Wachsen Sie den Stack von innen nach außen. Schema und Tools zuerst richtig; dann MCP, Skills oder Subagents unter Druck durch Wiederverwendung, Prozess oder Kontext. Validieren Sie Samples lokal vor dem Ship — Modelle können wechseln; Feldnamen und required sollten es nicht.