Wenn du in den letzten zwölf Monaten mehr als ein KI-Tool gebaut hast, ist dir dasselbe aufgefallen wie mir: Die Bandbreite an Möglichkeiten, „wie ein Modell mit Systemen spricht”, ist explodiert — Zeit für meinen Überblick über die KI-Tooling-Landschaft. Skills, MCP-Server, CLI-Tools, Computer Use, Function Calling, deklarative Agents, Custom-Engine-Agents, Apps, Actions, Extensions, Gems – jeder Anbieter verwendet ein leicht anderes Wort für etwas, das auf einer Marketing-Folie gleich aussieht. Es ist aber nicht dasselbe. Die Trade-offs sind real, die Wahl verändert die Architektur, und die falsche Entscheidung kostet Wochen.
Dieser Beitrag ist das mentale Modell, das ich inzwischen standardmäßig anwende, wenn ich etwas Agentisches baue. Es ist meinungsstark. Es ist kein Feature-Vergleich. Das Ziel ist, dir bei der Entscheidung zu helfen, zu welcher Oberfläche du zuerst greifst – nicht, die Spezifikation jeder einzelnen auswendig zu lernen.
Ich behandle sieben Oberflächen (die ursprünglichen fünf plus zwei, die 2026 zu wichtig sind, um sie zu überspringen), ordne sie der Terminologie von Anthropic, OpenAI, Microsoft und Google zu und gebe dir den Entscheidungsbaum, den ich tatsächlich verwende.
Inhaltsverzeichnis
Die Oberflächen, in klaren Worten
Ich definiere jede so, wie ich darüber denke, nicht so, wie es die Dokumentation tut.
1. Function Calling – das Original
Du gibst dem Modell ein JSON-Schema für einige Funktionen. Das Modell wählt eine aus und gibt Argumente aus. Dein Code führt die Funktion aus und liefert das Ergebnis zurück. Das unterstützt jedes moderne Frontier-Modell nativ: Anthropic nennt es Tool Use, OpenAI nennt es Function Calling (jetzt mit Strict Mode für garantierte Schema-Einhaltung), Google nennt es Function Calling in der Gemini-API. Es ist die niedrigste Abstraktionsebene und nach wie vor die berechenbarste.
Greife dazu, wenn du den Modell-Client kontrollierst und die Integration klein genug ist, dass das Verpacken in ein Protokoll nur Overhead wäre. Unterschätze nicht, wie weit du mit einem Dutzend gut typisierter Tools und einem präzisen System-Prompt kommst.
2. MCP – Model Context Protocol
Anthropics Protokoll, das einmaliges Function Calling in eine standardisierte Tool-Server-Architektur verwandelt. Du baust einen Server einmal (Tools, Resources, Prompts, Sampling), und jeder MCP-fähige Host kann mit ihm sprechen. Die Liste der Hosts ist längst nicht mehr Anthropic-spezifisch: OpenAI hat MCP Anfang 2025 übernommen, ChatGPT Apps laufen unter der Haube auf MCP, Microsoft Copilot Studio unterstützt MCP-Server als Connector-Typ, und IDEs wie Cursor, Windsurf und der Agent-Modus von VS Code sprechen es alle.
Zwei Transports sind heute relevant: stdio für lokale Server, die auf dem Rechner des Nutzers laufen, und Streamable HTTP (mit OAuth 2.1) für gehostete Multi-User-Server. Die gehostete Variante macht MCP im großen Maßstab interessant – ein Server, viele Mandanten, browserbasierte Authentifizierung.
Greife dazu, wenn die Integration wiederverwendet wird – mehrere Hosts, mehrere Nutzer, mehrere Agents. Der Preis ist ein zusätzlicher Hop in der Architektur und ein etwas schwergewichtigeres Deployment. Der Vorteil: Deine Investition zahlt sich über jeden KI-Client aus, den dein Team in Betrieb nimmt.
Wo MCP falsch eingesetzt wird: einen einzelnen In-App-Agent bauen und dessen drei interne Helfer als MCP-Server verpacken. Das ist Over-Engineering. Verwende dort Function Calling.
3. CLI-Tools – der überraschende Gewinner
Das habe ich in meinem früheren Beitrag über CLI-Tools, die MCP schlagen behandelt. Kurzfassung: Wenn ein Agent in einer Bash-Umgebung läuft (Claude Code, die OpenAI Codex CLI, Cursors Terminal-Agent, jeder terminalbasierte Assistent), sind vorhandene CLIs bereits perfekte Tools. Sie haben Flags, strukturierte Ausgabe (oft JSON via --output json), Exit-Codes, Manual-Pages und jahrzehntelange Betriebsstabilität. Du musst nichts bauen – du musst nur einen guten Prompt schreiben.
Greife dazu, wenn der Agent ein entwicklerorientierter Assistent ist, der bereits eine Shell hat. Zu versuchen, kubectl, az, gh oder pwsh hinter einem eigenen MCP-Server zu verpacken, bedeutet, Infrastruktur neu zu erfinden, die bereits funktioniert. Die Ausnahme: Wenn die Ausgabe der CLI zu umfangreich für das Kontextfenster ist oder wenn die CLI interaktive Eingaben verlangt, durch die ein Modell nicht navigieren kann – dann rechnet sich ein dünner MCP-Wrapper, der getrimmtes JSON zurückgibt.
4. Computer Use
Anthropics Muster (und mittlerweile auch OpenAIs Computer Use in der Responses-API / Operator sowie Microsofts Computer Use in Copilot Studio), bei dem das Modell einen Screenshot sieht, entscheidet, wohin es klickt, und Maus- und Tastatur-Aktionen ausgibt. Pixel rein, Aktionen raus. Das ist die Antwort für Systeme, die keine API haben – Legacy-Enterprise-Tools, In-Browser-SaaS ohne OAuth, Anwendungen, die du nicht skripten kannst oder willst.
Es ist außerdem die langsamste, teuerste und unzuverlässigste der sieben Oberflächen. Verwende es, wenn du musst, niemals dann, wenn du ein Tool mit stabilem Schema nutzen kannst. Zwei weitere Punkte: Sicherheit ist hier wichtiger als irgendwo sonst (Prompt Injection über Bildschirminhalte ist real – siehe Anthropics Beiträge zu Claude in Chrome), und Observability ist nicht verhandelbar. Wenn du den Screenshot-Stream nicht erneut abspielen kannst, sobald etwas kaputtgeht, kannst du es nicht debuggen.
5. Gehostete Tools – Code-Ausführung, Retrieval, Websuche
Das ist die Kategorie, die das ursprüngliche Fünf-Oberflächen-Modell übersieht. Jeder große Anbieter liefert mittlerweile First-Party-Tools, die du nicht selbst implementieren musst: Code-Ausführungs-Sandboxes (Anthropics Code-Execution-Tool, OpenAIs Code Interpreter, Geminis Code-Ausführung), Retrieval über hochgeladene Dateien (OpenAIs file_search, Anthropics Files-API, Geminis File-API) und Websuche als modellseitige Fähigkeit (Anthropics web_search_tool, OpenAIs web_search, Gemini-Grounding mit der Google-Suche).
Diese sehen in der API wie Function Calls aus, werden aber innerhalb der Infrastruktur des Anbieters ausgeführt. Du schreibst den Funktionskörper nicht. Du schaltest sie ein.
Greife dazu, wenn du sonst eine Sandbox, einen Vector Store oder einen Such-Wrapper neu erfinden würdest. Der Preis ist meist fair, die Integration ist eine Zeile, und die Fehlerfälle sind gut dokumentiert. Der Haken: Dein Agent hängt für diese Fähigkeit nun von der Infrastruktur des Anbieters ab, und ein Modellwechsel bedeutet, sie neu aufzubauen. Für alles wirklich Geschäftskritische (rechtlich regulierte Retrieval-Vorgänge, deterministische Code-Ausführung) baue es selbst.
6. Sub-Agents als Tool
Das Muster, das 2025–2026 explodiert ist: Ein Agent ruft einen anderen Agent auf, als wäre er ein Tool. Claude-Code-Subagents, OpenAIs Agents SDK mit Handoffs, Microsofts Multi-Agent-Orchestrierungen in Copilot Studio, LangGraphs hierarchische Graphen – alles dieselbe Form. Das „Tool” ist ein weiteres LLM mit eigenem System-Prompt, eigenem Tool-Set und eigenem Kontextfenster.
Greife dazu, wenn der Kontext eines Agents sonst überlaufen würde, wenn du einen Spezialisten mit engerem Tool-Set für eine Teilaufgabe willst (z. B. einen „Research-Agent” mit Websuche gegenüber einem „Writer-Agent” ohne Tools) oder wenn du eine parallelisierbare Teilaufgabe brauchst. Der Preis ist real: Der Token-Verbrauch vervielfacht sich, die Latenz stapelt sich, und eine Kette aus fünf Agents zu debuggen ist schwieriger, als einen Agent mit zwanzig Tools zu debuggen. Beginne mit einem Agent. Teile erst auf, wenn du Belege hast, dass der einzelne Agent an einer bestimmten Nahtstelle scheitert.
7. Skills – der Begriff, der vier verschiedene Dinge bedeutet
Das ist der Abschnitt, der die meiste Arbeit gemacht hat. „Skill” ist 2026 das am stärksten überladene Wort im Agent-Ökosystem. Vier verschiedene Konzepte teilen es sich:
Alexa Skills (Amazon, 2014): Sprach-Apps, die auf Nutzer-Intents reagieren. Weitgehend ein Relikt der Smart-Speaker-Ära, aber Amazon liefert das SDK weiterhin aus. Wenn jemand in deinem Meeting vor 2020 Sprach-Apps gebaut hat, ist das, was er hört, wenn du „Skill” sagst.
Microsoft Skills (Copilot Studio / Microsoft 365 Agents): Microsoft verwendet „Skill” als Sammelbegriff für zwei verschiedene Dinge. Deklarative Agents in Copilot Studio sind Low-Code-Integrationen – du verdrahtest Trigger, Wissensquellen und Actions in einem Designer. Custom-Engine-Agents, die mit dem Microsoft 365 Agents SDK gebaut werden, sind code-getrieben, laufen auf Azure und lassen dich das Modell und die Orchestrierung direkt steuern. Das ältere Bot Framework / Semantic Kernel verwendete ebenfalls „Skill” (Semantic Kernel hat sie inzwischen in „Plugins” umbenannt, aber alte Dokumentation hält sich hartnäckig). Wenn jemand bei einem Microsoft-Kunden sagt „wir haben einen Skill gebaut”, frage nach, welche dieser drei Varianten gemeint ist.
Anthropic Claude Skills (2025): eine Dateisystem-Konvention, kein Netzwerkprotokoll. Ein Skill ist ein Ordner, der eine SKILL.md-Datei (mit einer YAML-Frontmatter-Beschreibung) sowie beliebige unterstützende Skripte, Templates oder Referenzdateien enthält. Das Modell lädt SKILL.md nur dann, wenn die Aufgabenbeschreibung nahelegt, dass sie relevant ist – Progressive Disclosure. Der Inhalt sind Anweisungen an das Modell, wie man etwas gut macht: wie man eine pptx formatiert, wie man ein PDF-Formular ausfüllt, wie man eine Frontend-Komponente aufbaut. Skills sind keine Endpunkte. Sie sind wiederverwendbare Expertise-Bündel, die das Modell bei Bedarf entpackt. Verfügbar in Claude.ai, Claude Code und der Claude-API.
OpenAI verwendet „Skill” nicht – die nächsten Entsprechungen sind aber Custom GPTs (ein Bündel aus Persona + Instructions + Actions + Wissen, Distribution über den GPT Store), GPT Actions (OpenAPI-Schemas, die an externe APIs angebunden sind, die „veröffentlichte Function-Calling”-Oberfläche) und die neueren ChatGPT Apps, die am DevDay 2025 angekündigt wurden und MCP-Server in Kombination mit UI-Komponenten sind, die innerhalb von ChatGPT auffindbar sind.
Googles Entsprechungen sind Gems (Custom-GPT-äquivalente Personas in Gemini) und Extensions (tool-äquivalente Integrationen zu Google-Diensten und Drittanbietern).
Das Konzept einer „verpackten Fähigkeit, die du veröffentlichen und wiederverwenden kannst” ist real und nützlich. Die Benennung ist unglücklich. Sorge in Design-Dokumenten und Kundengesprächen immer für Klarheit.
Spickzettel zur Anbieter-Terminologie
Dasselbe Konzept, vier Namen. Lege diese Tabelle neben dein Architektur-Diagramm.
| Konzept | Anthropic | OpenAI | Microsoft | |
|---|---|---|---|---|
| Function Calling | Tool Use | Function Calling (Strict Mode) | Function Calling (im M365 Agents SDK) | Function Calling |
| Tool-Server-Protokoll | MCP (hat es geschaffen) | MCP (übernommen) | MCP (als Connector) | MCP-Unterstützung in AI Studio |
| Gehostete Code-Ausführung | Code-Execution-Tool | Code Interpreter | Python-Tool in Copilot Studio | Code-Ausführung |
| Gehostetes Retrieval | Files API + Suche | file_search | Wissensquellen in Copilot Studio | File API |
| Gehostete Websuche | web_search-Tool | web_search | Bing-Grounding | Grounding mit der Google-Suche |
| Computer Use | Computer Use, Claude in Chrome | Computer Use / Operator | Computer Use in Copilot Studio | (Project Mariner, Preview) |
| Verpackte Fähigkeit | Claude Skills | Custom GPTs / GPT Actions / ChatGPT Apps | Deklarative Agents / Custom-Engine-Agents / „Skills” | Gems / Extensions |
| Sub-Agent-Muster | Claude-Code-Subagents, Agent SDK | Agents SDK / Handoffs | Multi-Agent Copilot Studio | (noch kein First-Party-SDK) |
Der Entscheidungsbaum, den ich tatsächlich verwende
- Hat das Zielsystem bereits eine stabile API? Ja → Function Calling oder MCP. Nein → Computer Use als letztes Mittel.
- Wird die Integration von mehr als einem Host oder von mehr als einem Team genutzt? Ja → MCP, gehostet über Streamable HTTP. Nein → natives Function Calling.
- Ist der Agent bereits ein entwicklerorientierter CLI-Assistent mit einer Shell? Ja → rufe vorhandene CLIs aus Bash auf. Baue keine Tool-Schicht.
- Brauchst du Code-Ausführung, Dateisuche oder Websuche? Verwende zuerst das gehostete Tool. Baue es nur dann selbst, wenn Compliance, Determinismus oder Vendor-Lock-in die Investition rechtfertigen.
- Geht es um verpacktes Know-how darüber, wie man etwas tut, und nicht darüber, wie man ein System erreicht? Das ist ein Skill im Sinne von Claude – ein
SKILL.md-Bündel, kein Tool-Server. Andere Oberfläche, anderes Problem. - Ist deine Plattform Microsoft Copilot? „Skill” ist das Marketing-Wort; unter der Haube wählst du deklarative Agents (Copilot Studio) für Low-Code oder Custom-Engine-Agents (M365 Agents SDK) für volle Kontrolle.
- Läuft der Kontext eines Agents über oder gibt es eine saubere Spezialisten-Nahtstelle? Dann – und nur dann – teile in Sub-Agents auf.
- Ist der Workflow visuell oder nur per GUI bedienbar? Computer Use, aber investiere stark in Observability. Die Screenshot-Traces sind Gold wert, wenn etwas schiefgeht.
Fallstricke, die ich jetzt vermeide
Shell-Befehle in MCP verpacken, „weil Protokolle schön sind”. Sie sind schön. Sie sind aber auch zusätzliche Latenz, ein zusätzliches Deploy-Ziel und ein zusätzlicher Fehlerfall. Greife standardmäßig zu nativen CLIs, wenn der Agent eine Shell hat.
Computer Use als Ersatz für eine API behandeln. Wenn die API existiert und stabil ist, verwende sie. Computer Use existiert für die Fälle, in denen es sie nicht gibt.
Oberflächen in einem Agent ohne Planner mischen. Ein Agent, der vier MCP-Server, acht native Tools, gehostete Code-Ausführung und einen Computer-Use-Kanal hat, wird routinemäßig die falsche Oberfläche wählen. Wähle pro Agent eine primäre Oberfläche; route nur dann zu anderen, wenn die primäre versagt.
„Skills” über Anbieter hinweg verwechseln. Microsofts Skills, Anthropics Claude Skills, OpenAIs Custom GPTs und die ursprünglichen Alexa Skills sind vier verschiedene Konzepte. Sorge in Design-Dokumenten immer für Klarheit.
Zu früh zu Sub-Agents greifen. Multi-Agent sieht in Architektur-Diagrammen beeindruckend aus. Es vervielfacht aber auch Token-Kosten, Latenz und Debugging-Komplexität. Ein einzelner Agent mit einem guten Tool-Set schlägt in den meisten Fällen, die ich ausgeliefert habe, eine Sub-Agent-Konstellation.
Eigenes Retrieval bauen, bevor man das gehostete ausprobiert hat. Eine eigene Vector-Pipeline sind sechs Wochen Arbeit. file_search oder die Anthropic Files API ist ein API-Aufruf. Beginne gehostet, migriere erst, wenn du es überwachsen hast.
Vergessen, dass Computer Use eine Sicherheitsoberfläche ist. Bildschirminhalt ist nicht vertrauenswürdiger Input. Eine vergiftete Webseite kann einen Agent genauso kapern, wie eine bösartige E-Mail einen Nutzer kapern kann. Behandle jedes Pixel wie Nutzereingaben aus dem Internet – denn genau das ist es.
Wohin sich das entwickelt
Das Muster, von dem ich mittelfristig erwarte, dass es sich durchsetzt: Function Calling an der Modellgrenze, MCP an der Tool-Server-Grenze, gehostete Tools für die Capability-Schicht, CLIs und Computer Use als tatsächliche Ausführungsschicht und Skills (Bündel im Anthropic-Stil) für verpackte Expertise. Anbieter werden ihre eigenen Marketing-Begriffe behalten – Microsofts „Skills”, OpenAIs „Apps”, Googles „Extensions” –, aber die zugrunde liegenden Architekturen konvergieren schneller auf MCP, als ich es vor einem Jahr erwartet hätte.
Das Signal: OpenAI übernimmt MCP, ChatGPT Apps laufen darauf, Copilot Studio unterstützt es als Connector, jede IDE liefert einen MCP-Client aus. Das Protokoll hat die Integrationsschicht für sich entschieden. Was noch zu entscheiden bleibt, ist, welche Fähigkeiten du baust, welche du hostest und welche du an Sub-Agents delegierst.
Wenn du dir aus diesem Beitrag sonst nichts merkst: Wähle pro Agent eine primäre Oberfläche, richte sie danach aus, ob das Zielsystem eine stabile API hat, und greife erst dann zu den schwergewichtigeren Abstraktionen, wenn Wiederverwendung, Skalierung oder Fähigkeit es wirklich rechtfertigen. Alles andere ist Over-Engineering mit zusätzlichen Schritten.
