- Der Claude Developer Platform wurden drei neue Funktionen hinzugefügt, die eine erweiterte Tool-Nutzungsarchitektur bereitstellen, mit der das Modell Tausende externer Tools effizient durchsuchen, aufrufen und erlernen kann
- Das Tool Search Tool lädt Tool-Definitionen nur dann, wenn sie benötigt werden, und reduziert so den Token-Verbrauch um bis zu 85 %; in großen MCP-Umgebungen steigt zudem die Genauigkeit um 74–88 %
- Programmatic Tool Calling ruft Tools in einer Code-Ausführungsumgebung parallel auf und erreicht dadurch Token-Einsparungen (37 %), geringere Latenz und höhere Genauigkeit
- Tool Use Examples ermöglichen es, über reale Aufrufbeispiele Tool-Nutzungsmuster und Parameterbeziehungen zu erlernen, die sich nicht mit JSON Schema ausdrücken lassen
- Die drei Funktionen liefern eine Grundlage für die effiziente Orchestrierung großer KI-Agenten und sind ein zentraler Baustein für die Automatisierung komplexer Workflows
Skalierung der Tool-Nutzung von KI-Agenten
- Künftige KI-Agenten müssen Hunderte bis Tausende von Tools integriert nutzen
- Als Beispiele werden IDE-Hilfstools, Betriebskoordinatoren sowie Integrationen mit Slack, GitHub, Jira und Google Drive genannt
- Der bisherige Ansatz musste alle Tool-Definitionen im Voraus laden und verbrauchte dadurch das Kontextfenster (context window) sehr schnell
- Der neue Ansatz durchsucht und lädt Tools bei Bedarf und gewinnt Effizienz durch codebasierte Aufrufe und Lernen anhand von Beispielen
Tool Search Tool
- In bestehenden MCP-Umgebungen belegen Tool-Definitionen bei Verbindungen zu vielen Servern mehr als 100.000 Tokens
- Beispiel: GitHub (26K), Slack (21K), Jira (17K); zusammen wurden Fälle mit mehr als 134K Tokens beobachtet
- Das Tool Search Tool sucht und lädt Tools on-demand
- Beim initialen Laden werden nur etwa 500 Tokens verbraucht, zusätzliche Tools werden nur bei Bedarf nachgeladen
- Der gesamte Token-Verbrauch sinkt auf etwa 8,7K, was 95 % Kontexteinsparung bedeutet
- Interne Tests zeigen eine Verbesserung der MCP-Evaluationsgenauigkeit: Opus 4: 49 %→74 %, Opus 4.5: 79,5 %→88,1 %
- Mit der Einstellung
defer_loading: true können Tools verzögert geladen werden
- Nur häufig genutzte Tools bleiben immer geladen, alle anderen werden erst beim Suchzeitpunkt geladen
- Regex- und BM25-basierte Suchtools werden standardmäßig bereitgestellt, auch embeddingbasierte benutzerdefinierte Suche ist möglich
- Empfohlene Einsatzbedingungen: mehr als 10 Tools, mehr als 10K Tokens an Definitionen, Umgebungen mit häufigen Auswahlfehlern
Programmatic Tool Calling
- Herkömmliche auf natürlicher Sprache basierende Aufrufe sind wegen akkumulierter Zwischenergebnisse und mehrerer Inferenzdurchläufe ineffizient
- Beispiel: Bei der Analyse eines 10-MB-Logs landet der gesamte Datensatz im Kontext und verschwendet Tokens
- Programmatic Tool Calling (PTC) ruft Tools parallel in einer Code-Ausführungsumgebung auf
- Claude führt mit Python Schleifen, Bedingungen und Datentransformationen aus
- Zwischenergebnisse werden nicht in den Modellkontext aufgenommen, nur das Endergebnis wird zurückgegeben
- Beispiel: Bei der Suche nach Budgetüberschreitungen pro Quartal wird statt 2.000 Einträgen nur ein Ergebnis von 1 KB in den Kontext aufgenommen
- Effekte
- Token-Verbrauch 43.588→27.297 (37 % weniger)
- Kürzere Latenz (bei 20 Aufrufen entfallen 19 Inferenzschritte)
- Höhere Genauigkeit: interne Suche 25,6→28,5 %, GIA-Benchmark 46,5→51,2 %
- Empfohlene Einsatzbedingungen
- Zusammenfassung großer Datenmengen, abhängige Aufrufe über drei oder mehr Schritte, Aufgaben mit Bedarf an Parallelausführung
- Für Einzelaufrufe oder kleine Antworten ineffizient
Tool Use Examples
- JSON Schema definiert nur Struktur, kann aber Nutzungsmuster, Formatregeln und Parameterbeziehungen nicht ausdrücken
- Zum Beispiel bleiben Datumsformate, ID-Regeln oder der Einsatzzeitpunkt verschachtelter Objekte unklar
- Tool Use Examples ergänzen Tool-Definitionen um reale Eingabebeispiele (
input_examples)
- Anhand der Beispiele lernt Claude etwa Datumsformate (YYYY-MM-DD), ID-Regeln (USR-XXXXX) oder Kombinationen optionaler Parameter
- In internen Tests stieg die Genauigkeit bei der Verarbeitung komplexer Parameter von 72 % auf 90 %
- Empfohlene Einsatzbedingungen
- Tools mit verschachtelten Strukturen und vielen optionalen Parametern
- APIs, deren domänenspezifische Regeln sich nicht im Schema ausdrücken lassen
- Fälle, in denen ähnliche Tools voneinander abgegrenzt werden müssen
Integrierte Nutzung der drei Funktionen und Best Practices
- Die drei Funktionen arbeiten komplementär zusammen
- Tool Search Tool → benötigte Tools finden
- Programmatic Tool Calling → effiziente Ausführung
- Tool Use Examples → präzise Aufrufe
- Priorisierung für den Einsatz
- Kontextüberlauf → Tool Search Tool
- Zu viele Zwischenergebnisse → Programmatic Tool Calling
- Parameterfehler → Tool Use Examples
- Konfigurationstipps
- Tool-Namen und Beschreibungen klar formulieren, um die Suchgenauigkeit zu verbessern
- Drei bis fünf häufig genutzte Tools immer laden, den Rest verzögert laden
- Für Tools zur Code-Ausführung das Rückgabeformat festlegen
- Beispieldaten realistisch und kompakt halten (1–5 Beispiele)
Erste Schritte
- Die drei Funktionen werden als Beta-Version bereitgestellt
- Nach Hinzufügen des Headers
betas=["advanced-tool-use-2025-11-20"] nutzbar
- Enthaltene Tools:
tool_search_tool_regex_20251119, code_execution_20250825 usw.
- In der offiziellen Dokumentation und im GitHub-cookbook gibt es API-Beispiele und Implementierungsleitfäden
- Die Funktionen werden als Basistechnologie präsentiert, die über einfaches Function Calling hinaus zu intelligenter Orchestrierung führt
- Hervorgehoben werden sie als zentrale Bausteine, um in komplexen Workflows und großen Datenumgebungen dynamische Suche, effiziente Ausführung und präzise Aufrufe zu ermöglichen
5 Kommentare
Aber bisher scheint es eher am Modell zu liegen. Dass das so gut funktioniert, liegt wohl daran, dass es die Modelle sind, die Claude selbst anbietet — ob das mit anderen Modellen auch so gut klappt, ist fraglich ...
Unter Unternehmen wie Anthropic, Google und OpenAI habe ich das Gefühl, dass Anthropic am ehesten in Richtung Agentic AI geht.
Hacker-News-Kommentare
Ich suche nach einer Möglichkeit, bei der Verarbeitung mehrerer tool calls im Streaming den Context-Verbrauch zu reduzieren.
Einen Teil der Verarbeitung auf das Tool selbst auszulagern und es 200k-Token-Markdown als Zusammenfassungsstruktur zurückgeben zu lassen, hilft zwar, aber auch so kann der Context des Hauptmodells schnell volllaufen.
Ich denke, Programmatic Tool Calling ist der natürliche nächste Schritt.
LLMs entwickeln sich in eine Richtung, in der sie Code wie eine Sprache behandeln, daher ist die Definition dieser Sprache wichtig.
Tool Search halte ich jedoch für unnötigen Overhead. Es ist effizienter, die benötigten Tools vorab in den Context zu legen.
Letztlich braucht es eine kompakte tool definition language ähnlich einer Funktionsdefinition; ideal wäre, Objekte in den Context zu geben und das Modell deren Typen sowie aufrufbare Methoden erkennen zu lassen.
.d.tsbereitstellen.Das wäre einfacher zu warten und zu testen, und bei Bedarf könnte man sie mit etwas wie
export * as Foo from '@foo/foo'einbinden.Da LLMs auch beim Schreiben von Code gut sind, könnten sie mit Schreibrechten Tools selbst erstellen oder importieren.
Langfristig scheint mir eine interaktive AI↔Mensch-Kollaborationsplattform wie Jupyter/Pluto/Mathematica besser geeignet.
Wenn man dazu Spracheingabe ergänzt und Zusammenarbeit über mehrere Sessions hinweg ermöglicht, käme das fast an ein Skynet-System heran.
Der Agent, den ich gebaut habe, funktioniert allein mit einem Teil der Python-SDK-Funktionen und einigen Custom Functions ausreichend gut.
Diese pseudo-RPC-Struktur wirkt auf mich wie ein unnötiges Ritual.
Smolagents nutzt das, um Tool-Ausgaben als Objekte (dict) zu behandeln.
Ich frage mich, ob dieser Ansatz in die Richtung geht, die ich meine.
Mehr dazu steht in diesem Blogpost von Hugging Face.
Ich frage mich, ob MCP-Server Nutzungsbeispiele in Tool-Definitionen aufnehmen werden.
Falls ja, könnte man auch Codebeispiele mitgeben und den Schritt der Codegenerierung überspringen, aber vermutlich wurde das wegen Sicherheitsproblemen verhindert.
Von Dritten bereitgestellten Code auszuführen ist riskant, daher ist diese Entscheidung nachvollziehbar.
Schade, dass Python als Wrapper verwendet wurde.
Mit Bash wäre die Kompatibilität zwischen Sprachen höher gewesen und es hätte auch zu Workflows gepasst, die kein Python verwenden.
Es kann externe Tools praktisch genauso gut ausführen wie Bash.
Die Vision einer Zukunft, in der das Modell Hunderte bis Tausende von Tools nahtlos handhabt, scheint mir falsch zu sein.
Ich denke eher, dass weniger Tools + bessere Nutzung die richtige Richtung ist.
Im Extremfall könnte sogar ein einziges ShellTool ausreichen.
Ideal wäre ein Ansatz, bei dem das Modell selbst Tools erstellt, testet und lernt, ihnen zu vertrauen.
Das Connector-Ökosystem ist leicht zu verstehen und gut zu vermarkten, aber grundsätzlich wirkt es wie ein falsches Paradigma.
Ich fände ein kleines lokales Orchestrator-Modell sinnvoll.
Es ist oft ineffizient, den gesamten Workflow programmatisch zu orchestrieren.
Um Context-Verschmutzung zu reduzieren und die Geschwindigkeit zu erhöhen, wäre eine Struktur programmatic > tiny local LLM > frontier LLM ideal.
Das kleine Modell könnte seinen Context häufig zurücksetzen und nur die nötigen Ergebnisse an das große Modell weitergeben.
Bei der Nutzung von AI-Assistenten tauchen immer wiederkehrende Muster auf.
Wenn ich eine ineffiziente Methode selbst verbessere, erscheint ein paar Monate später ein neues Tool und macht meine Arbeit bedeutungslos.
Ich sehe das als den Preis dafür, stets dem neuesten Stand der Technik hinterherzulaufen.
Irgendwann wird das gesamte Web wohl aus Milliarden von Tools bestehen.
Google wird sie indexieren, und Gemini wird sie dynamisch auswählen, um in der Welt zu handeln.
Ehrlich gesagt hatte ich so etwas bereits von Gemini 3 erwartet.
Die hier beschriebene Funktion Nr. 2 ist eine Umsetzung des zuletzt viel diskutierten Konzepts, Tools nicht direkt aufzurufen, sondern sie durch geschriebenen Code aufzurufen.
Das läuft in einer Python-Sandbox, ist auch über eine API zugänglich und stellt Tool-Aufrufe wie gewöhnliche API-Aufrufe bereit.
Batch tool calling hat die Geschwindigkeit des AI-Assistenten in unserem Produkt bereits deutlich erhöht, und diese neue Funktion wirkt wie dessen Weiterentwicklung.
Unser agentic builder verwendet genau ein einziges Tool — nämlich GraphQL.
Der Agent schreibt Queries, führt sie aus und erhält per Introspection die benötigten Informationen.
So lassen sich mit nur minimalen Daten Token sparen.
Es ist nicht nötig, über 50 Tools zu laden, und auch das N+1-Problem von REST APIs wird vermieden.
Dank des getypten GraphQL-Schemas schreibt der Agent besseren Code.
Früher mochte ich GraphQL nicht, aber wenn ich mir den aktuellen Zustand von MCP ansehe, scheint es mir eine der am besten geeigneten Technologien für AI-Agenten zu sein.
Mehr dazu habe ich in diesem Beitrag zusammengefasst.
Mein Agent führt nur eine einzige SPARQL-Query aus, und der Zustand liegt ausschließlich in einer Graph-Datenbank.
Die meisten Ontologien sind öffentlich, daher ist Schema-Introspection fast nie nötig.
Durch strukturierte Ausgaben kann ich erzwingen, dass nur gültiges RDF erzeugt wird.
In GraphQL dürfte sich etwas Ähnliches umsetzen lassen.
Ich muss verschiedene Aufgaben erledigen, etwa Websuche, lokale API-Aufrufe und Slack-Integrationen, daher reicht GraphQL allein nicht aus.
Es gibt zwar Themen wie Berechtigungen, Caching und Mutations, aber auf selektives Context-Laden hat das kaum Einfluss.
Das LLM schreibt GraphQL-Queries passend zum Schema ziemlich gut.
Selbst wenn es Fehler macht, korrigiert es sie schnell, wenn die Fehlermeldungen gut sind.
Die zugrunde liegenden Überlegungen sind in diesem Blogpost beschrieben.
Ich fand sonnet 4.5 auch schon ziemlich gut.
opus 4.5 scheint aber noch besser zu sein. Wow.
Ach ja? Woran liegt das hauptsächlich?