Tutorial
Warum AI-Agenten von Tool Calling zu Skills + Plugins wechseln: Architektur 2026 und der JSON-Datenfluss
Tool Calling ist nicht veraltet. Veraltet ist, jedes Tool-Schema und das ganze Handbuch in einen Request zu stopfen.
Wir haben schon was die Agent-Schleife ist, wie dieser MCP-Hopp Arguments prüft und wie man Skills / MCP / Plugin wählt geschrieben. Das wiederholen wir nicht. Im Review hören Sie eine andere Zeile: „Wir haben doch Tool Calling — wozu Skills und Plugins?“ Das ist Architektur, kein Feld-Ausfüllen. Die Gründe sind konkret. Zu viele Tools, und die volle Schema-Tabelle frisst das Fenster. Zu langer Prozess, und die SOP im System-Prompt wird abgeschnitten. Client wechseln, und Brief und Hand gabeln. Agent Skills schrumpft Entdeckung per Progressive Disclosure auf name + description. Agent Plugins 1.0.0 spezifiziert die Kiste, nicht den Aufruf. Google sagt dasselbe: ein Skill, ein MCP, ein Client braucht keine Kiste. Dieser Text legt den alten Request neben die neue Spur als JSON.
Der Aufruf hält; die Entdeckungsfläche nicht
Tool Calling ist weiter der Hopp, in dem das Modell Funktionsname und Arguments wählt. 2026 hat das niemand pensioniert. Pensioniert ist eine Packgewohnheit: beim Start fünfzig inputSchema-Dokumente in tools[] schütten, dann „zuerst Projekt prüfen, dann Billing, Wochenbericht wie Finance“ in system kleben. Zehn Tools gehen. Eine dritte Fachdomäne später wird der Request selbst ein Riesen-JSON, das niemand diffed. Ein falsches Tool wirkt wie Halluzination. Meist ist die Entdeckungsfläche zu breit und der Brief abgeschnitten. Der Aufruf-Hopp ist nicht kaputt. Sie haben ihn Entdeckung mitmachen lassen.
Das Fenster ist nur der erste Schnitt. Der zweite ist Änderung. Finance ändert die Abschnittsreihenfolge, und Sie editieren System-Prompt, internes Wiki und drei IDE-Pasten. Ohne diffbare SKILL.md kommt man nie in einen PR. Der dritte Schnitt ist Client-übergreifend: Cursors MCP-Dialekt, Claude Codes Skill-Verzeichnis, Antigravitys Plugin-Layout — drei Hüllen. Die Tools sind dieselben; die Kisten gabeln zuerst. Der Schmerz sitzt nicht im tools/call-Umschlag. Er sitzt außen: wann nutzen, was muss mitreisen.
„Hin zu Skills + Plugins“ ist also kein Slogan-Tausch. Entdeckung und Packung werden aus dem Aufruf-Request gezogen. Der Aufruf-Hopp bleibt — siehe MCP und JSON Schema. Die Agent-Schleife bleibt — siehe den Definitions-Text. Heute nur, wie JSON nach der Trennung fließt. Was der Client nach der Installation hält, ist Plugin-Manifest in der Praxis — fünf Hopps. Dieser Text ist, warum die fünf Hopps entstanden.
| Diese Schicht | Alte Gewohnheit | Gewohnheit 2026 |
|---|---|---|
| Wann ein Prozess gilt | Langer Absatz im System-Prompt | Skill-description (~100 Token) |
| Welche Hände es gibt | Die volle tools[] im Request | tools/list nach Plugin-Install oder MCP-Connect |
| Der eigentliche Aufruf | Modell-Arguments → Runtime | Unverändert: weiter parse + Schema |
Kein Ersatz: die Aufrufschicht bleibt, eine Schicht sitzt darüber
Skills „das nächste Tool Calling“ nennen, und Sie debuggen in den Logs die falsche Schicht. Ein Skill hat kein tools/call. Es ist ein Brief. Der Start injiziert nur Metadaten. Das Modell trifft einen Auslöser, dann liest es Body und scripts/. MCP ist die Hand. Ein Plugin ist ein Verzeichnis. Die drei sitzen über dem Aufruf; sie ersetzen den Arguments-Hopp nicht. Eine ehrliche Spur zeigt weiter ein legales tools/call. Fehlt es, hat Entdeckung das Modell blockiert — die Aufrufschicht wurde nicht gelöscht.
Progressive Disclosure ist der Kern der Agent-Skills-Spez, kein Marketing-Adjektiv. name max. 64, description max. 1024, dritte Person, was es tut und wann. Ein interner Codename oder Ich-Slogan nullt die Entdeckungsfläche — die Tools sind da, das Modell wählt sie nie. Den Body bei Bedarf zu laden hält Runbook und fünfzig Schemas vom selben Fenster fern. Skripte bleiben argv, keine erstklassigen Tools aus tools/list. Stabiles JSON-Input heißt weiter MCP.
Ein Plugin ist dünner. Es darf keine Tool-Liste inline und keine SOP oben in plugin.json ablegen. Die Kiste sagt, ob dieser Brief und diese Hand da sind. Der Aufruf sagt, ob die Arguments dieses Hopps legal sind. Zwei JSON-Dateien, zwei Jobs. Die vier Entscheidungsfragen stehen im Auswahl-Text; die fünf Hopps nach Install im Manifest-Text. Heute zeichnen wir nur, wie der Fluss von flach nach dick ging.
Alter Fluss: ein riesiges tools-Array
Der alte Request sieht aus wie Speisekarte plus Hausregeln. Jeder tools-Eintrag trägt ein volles inputSchema. system hält den Prozess. Ein Nutzersatz, und das Modell bestellt von der ganzen Karte. Eine kurze Karte ist schnell. Wird sie Rechnungen + Spesen + IAM + Deploy + Dokusuche, scheitert zuerst das Bestellen: ähnliche Tools konkurrieren, die SOP endet mitten in „keine Secrets committen…“. Das Ticket sagt, das Modell sei durchgedreht. Ein Diff sagt, der Request-Body sei zuerst durchgedreht.
Dieses JSON hat versteckte Kosten: die Runtime hat es gebaut, oft liegt es nie im Repo. Jemand fügt send_slack hinzu, und kein PR zeigt, wie die Schemas wuchsen. Review hängt an dem Riesenkörper in den Logs. Ohne Budget kein Signal, Entdeckung auszulagern. Flache Architektur ist kein Moralfehler. Es ist Wachstum ohne Zähler.
Unten ein abgeflachtes altes Fixture. Produktion ist länger. Erst parsen, dann CI-Budget auf tools.length und Request-Bytes. Das Budget zu reißen heißt nicht „noch eine Prompt-Zeile“. Es heißt, SOP und volle Schemas aus dem Start-Request zu holen.
{
"era": "flat-tool-calling",
"system": "Always check the billing project first. Never commit secrets. Write the weekly invoice summary the finance team actually reads.",
"tools": [
{
"name": "query_invoices",
"inputSchema": {
"type": "object",
"required": ["week"],
"properties": {
"week": { "type": "string", "pattern": "^[0-9]{4}-W[0-9]{2}$" },
"status": { "type": "string", "enum": ["open", "paid", "overdue"] }
}
}
},
{
"name": "export_csv",
"inputSchema": {
"type": "object",
"required": ["week"],
"properties": { "week": { "type": "string" } }
}
},
{
"name": "send_slack",
"inputSchema": {
"type": "object",
"required": ["channel", "text"],
"properties": {
"channel": { "type": "string" },
"text": { "type": "string" }
}
}
}
]
}
Neuer Fluss: Metadaten → Body → Tool-Vertrag
Die neue Spur wird bei Bedarf dick. Start: nur Skill-Metadaten im Kontext (plus Plugin-Identität, falls eine Kiste installiert ist). Match: dann den SKILL.md-Body lesen. Eine Hand braucht: dann dieses inputSchema aus tools/list ins Fenster. Aufruf: Arguments bestehen weiter dieselbe Schema-Prüfung. Was gleichzeitig im Fenster sitzt, geht von „volle Karte + volle Hausregeln“ zu „ein Index + das geöffnete Buch“. Token wandern von der Startrechnung zur Match-Rechnung.
tools[] ist nicht verschwunden. Es ist später. Später kostet einen Handshake mehr und eine weitere Match-Fehlerart. Schwache description, und das Modell erreicht Hopp drei nie; Nutzer sagen „Plugin installiert, kann trotzdem nicht.“ Das ist ein Entdeckungsbug, kein zurückkehrendes Tool Calling. Das Inverse — Spur hat schon inputSchema, Runbook wandert trotzdem nach system — ist die neue Architektur rückwärts. Die Fensterrechnung kommt zurück.
Unten das neue Fixture derselben Aufgabe. Keine Spez-Datei. Eine Review-Spur. Gegen den alten Request diffen: die SOP wanderte von system nach skills[].description, die Schemas vom Start nach afterMatch.tools. Der query_invoices-Vertrag der Aufrufschicht bleibt ein kanonisches Schema. Kein zweites Feldset „für die neue Architektur“.
{
"era": "skills-plus-plugins",
"startup": {
"plugin": "invoice-ops",
"skills": [
{
"name": "write-weekly-summary",
"description": "Turn invoice query results into the weekly summary finance reads. Use when the user asks for a week-end report.",
"loaded": "metadata"
}
]
},
"afterMatch": {
"skillBodyLoaded": true,
"tools": [
{
"name": "query_invoices",
"source": "mcp:invoice-tools",
"inputSchema": {
"type": "object",
"required": ["week"],
"properties": {
"week": { "type": "string", "pattern": "^[0-9]{4}-W[0-9]{2}$" },
"status": { "type": "string", "enum": ["open", "paid", "overdue"] }
}
}
}
]
}
}
Warum trotzdem ein Plugin: Brief und Hand müssen zusammen reisen
SOP als Skill, API als MCP — der Request wird schon dünner. Ein zweiter Client, und Verzeichnisplus MCP-Dialekt gabeln wieder. Ein Plugin lohnt, wenn Brief und Hand zusammen reisen müssen. Das Google Cloud Developer Plugin packt gcloud-Geländer-Skill und Developer-Knowledge-MCP deshalb, nicht weil Tool Calling zu schwach war. Die Kiste führt kein Tool aus. Sie hält den Entdeckungspfad über Antigravity, Claude Code und Cursor zusammen.
Ein Client, ein Server: native MCP-Config behalten. Ein Plugin „um modern zu sein“ ist nur ein weiteres Manifest. Fragen drei und vier im Entscheidungs-Text gelten weiter. Der Architekturwechsel heißt nicht „alle auf Plugin“. Er heißt „Aufrufschicht stabil; Entdeckung und Packung dort, wo es weh tut.“ Kein zweiter Client, Brief hängt nicht an der Hand: bei Skill oder nativem MCP zu stoppen ist korrekte Architektur 2026.
Die A2A-Linie noch einmal. Wie ein anderer Agent gefunden wird, ist eine Agent Card, nicht dieser Agent in tools[]. Die andere Explosion flachen Tool Callings: einen Remote-Agenten als eine Funktion behandeln. Das sprengt die Arguments-Form. Horizontale Delegation ist nicht heutiger Fluss. Heute nur: wie dieser eine Agent weniger Karte und mehr Index trägt.
| Symptom | Diese Schicht zuerst | Nicht tun |
|---|---|---|
200KB Request, 40 Einträge in tools | Entdeckung: Skill-Metadaten + Schemas bei Bedarf | System-Prompt noch länger machen |
| Nach IDE-Wechsel Brief und Hand uneins | Packung: Plugin-Verzeichnis | Noch einen Client-Dialekt kopieren |
| Richtiges Tool, Wochenbericht trotzdem falsch | Brief: SKILL.md-Body | Leeres format_report-Tool addieren |
Beide Fixtures nebeneinander diffen
Mindestens drei Review-Fixtures: der alte Request oben, die neue Spur, ein echtes query_invoices-Arguments-Objekt. Die ersten zwei besitzen „welche Schicht gab den Ballast ab“. Die dritte beweist, dass die Aufrufschicht nicht umgeschrieben wurde — inputSchema ist weiter das kanonische. Plugin-name in Tool-Arguments oder inputSchema in plugin.json sieht man im Diff sofort.
Zwei Negative: neue Spur mit leerem skills, die trotzdem era skills-plus-plugins behauptet; alter Request über Budget bei tools.length ohne Split-Protokoll. Ersteres fängt Slogan ohne Entdeckungswechsel. Letzteres fängt „Prompt einfach länger“. Kein Geheimnis in committed Fixtures.
Im Browser reicht:JSON formatieren, um alten Request und neue Spur zu parsen;JSON-Schema prüfen, um inputSchema und Arguments zu prüfen;JSON Diff, um altes system / tools neben neues skills / afterMatch zu legen. Nichts verlässt die Maschine. Weiterlesen:MCP und JSON Schema, der Entscheidungstext und die fünf Manifest-Hopps.
Verwandt: Was ist ein AI Agent, MCP und JSON Schema, Skills vs MCP vs Plugins, Plugin-Manifest in der Praxis.
FAQ
Sollen wir Tool Calling löschen?
Nein. Das Modell wählt weiter Funktionsname und Arguments; die Runtime sendet weiter tools/call. Sie löschen die volle Karte beim Start, nicht den Aufruf-Hopp. Fehlt in der Spur ein legaler Aufruf, zuerst Entdeckung, dann Runtime.
Nur Skill, kein Plugin — ist das die neue Architektur?
Das ist die Entdeckungsschicht. Die SOP verließ den System-Prompt und lädt bei Bedarf; der Request wird dünner. Es ist nicht die Packungsschicht. Ein Client reicht: dort stoppen. Ein zweiter erscheint, Brief muss mit der Hand: dann ein Plugin.
Ist jedes Schema im Start-Request nicht schneller?
Kurze Karte, stabile Tools, ein Client — ja, und einfacher. Über Budget, in Zahl oder Bytes, fressen falsche Tool-Wahlen die gesparte Latenz. Budget vor Gefühl.
Kriegt das mit Programmatic Tool Calling?
Nein. Programmatic Tool Calling ist Struktur auf der Aufrufschicht: das Modell kettet Tools bewusst. Skills + Plugins sind Entdeckung und Packung: welchen Brief lesen, welche Hand verbinden. Zuerst Index, dann Kette.
Fazit und nächste Schritte
2026 schrumpft „von Tool Calling zu Skills + Plugins“ auf einen Satz: der Aufruf-Hopp bleibt; Entdeckung und Packung verlassen den Riesen-Request. Das Modell bestellt weiter. Die ganze Karte liegt nicht mehr beim Hinsetzen auf dem Tisch.
Ausliefern so: Budget auf tools.length und Bytes des alten Requests; SOP in eine description falten; volle Schemas hinter den Match; plugin.json, wenn ein zweiter Client kommt. Alten Request und neue Spur in JSONVue nebeneinander. Schleife: Agent-Text. Arguments: MCP-Text. Packen: Entscheidungstext.