# Tool-Use: Design, Selektion, Sicherheit > Tools sind das Interface des Agenten zur Welt: gutes Tool-Design, eine kleine orthogonale Menge, Parameter-Validierung, Fehlerbehandlung, Least-Privilege und der Umgang mit dem, was Tools zurückgeben. Track: [Agentic AI](https://physar.tech/learn/agentic-ai) Kanonische Fassung: https://physar.tech/learn/agentic-ai/agent-tool-use Stand: 2026-07-22 Interaktiver Teil: 8 Checks (nur im Browser) ## Tool-Use: das Interface des Agenten zur Welt ### Tools bestimmen, wie gut ein Agent ist Ein Agent handelt über **Tools** — Funktionen, die er aufrufen kann. Das Modell **wählt** anhand von Name, Beschreibung und Schema, welches Tool es mit welchen Argumenten aufruft. Die Qualität der Tools deckelt damit die Qualität des Agenten: schlechte Tools ergeben schlechte Agenten, egal wie fähig das Modell ist. > **Kernidee:** Behandle eine Tool-Definition wie eine **API für das Modell**: so präzise, typisiert und eng, wie du eine Schnittstelle für einen anderen Dienst entwerfen würdest. ### Gutes Tool-Design Ein Tool braucht einen **aussagekräftigen Namen**, eine **klare Beschreibung** (was es tut, wann es zu nutzen ist) und ein **typisiertes Schema** für die Parameter (Name, Typ, erlaubte Werte). `get_data(x)` mit „gets data“ lädt zu Fehlgebrauch ein — das Modell liest genau diese Beschreibung, um zu wählen und aufzurufen. > **Merksatz:** Vage Tool-Specs kann kein Prompt-Beispiel und kein größeres Modell voll reparieren. Die Definition **ist** das Interface. ### Kleine, orthogonale Tool-Menge Je mehr Tools — und je stärker sie sich **überschneiden** —, desto schwerer fällt dem Modell die Auswahl. Vier Tools, die alle „irgendwas suchen“, führen zu Fehlgriffen. Halte die Menge **klein und orthogonal**: klare, sich nicht überschneidende Zuständigkeiten. > **Kuratieren statt anleiten:** Der Fix für schlechte Tool-Selektion ist eine verschlankte Tool-Menge — nicht eine lange Prompt-Anleitung, welches Tool wann. ### Traue den Argumenten nicht Die Tool-**Argumente**, die das LLM erzeugt, sind **nicht vertrauenswürdige Eingabe**: sie können fehlformatiert, halluziniert oder gefährlich breit sein (ein leerer Filter, der alles löscht). Validiere sie am Tool-Rand (Schema, Grenzen, Plausibilität) vor der Ausführung. Und Tools **scheitern** — sie sollten **strukturierte, verwertbare Fehler** zurückgeben (was schiefging, ob retrybar), keinen rohen Stacktrace und keinen stillen Fehlschlag. Ein guter Fehler ist eine Beobachtung, aus der der Agent den nächsten Schritt ableitet. > **Enforcement, nicht Vertrauen:** Ein Prompt „erzeuge nur gültige Argumente“ ist keine Kontrolle. Validierung gehört in den Code am Tool-Rand. ### Least-Privilege & irreversible Aktionen Der **Blast-Radius** eines Tools ist gleich seinen **Rechten**. Gib jedem Tool die minimalen Berechtigungen (read-only, wo möglich; nur die nötigen Tabellen) — entscheidend, wenn der Agent untrusted Input verarbeitet, der ihn steuern könnte. **Irreversible/destruktive** Aktionen (Löschen, Zahlungen) dürfen nicht autonom aus einer LLM-Entscheidung feuern: ein erzwungener **Human-in-the-Loop**- oder Bestätigungs-/Dry-Run-Schritt davor, plus Limits. > **Außerhalb des Modells:** Rechte und Freigaben müssen **außerhalb** des Modells erzwungen sein — nicht per Prompt erbeten. Details im Security-Track (Least-Privilege, Excessive Agency). ### Was Tools zurückgeben Tool-**Ausgaben** fließen zurück in den Kontext — und sind damit zweierlei Problem: **Größe** (eine riesige Webseite bläht Kontext und Kosten, „lost in the middle“) und **Trust** (der Inhalt kann versteckte Anweisungen tragen — indirekte Prompt Injection über Tool-Output). > **Trust-Grenze am Rückweg:** Tool-Ausgaben **filtern/zusammenfassen** und als **untrusted** behandeln — die Vertrauensgrenze gilt auch auf dem Rückweg, nicht nur am Eingang (→ Security: Output-Handling & Injection). ### Tool oder Code? — gleich im Check Nicht alles gehört als Tool. Deterministische Logik, die **immer** (und in fester Reihenfolge) laufen muss, kodiert man fest im Ablauf — nicht als optionales, vom LLM gewähltes Tool, das es überspringen oder umsortieren kann. Tools sind für Aktionen, bei denen das Modell echt entscheiden soll. > **Gleich im Check:** Du entscheidest jetzt selbst: Tool-Design, Selektion, Argument-Validierung, Berechtigungen, irreversible Aktionen — und wo die Grenze zwischen Tool und Code verläuft. ## Quellen - Toolformer: Language Models Can Teach Themselves to Use Tools — Schick et al., 2023 - Building Effective Agents — Anthropic, 2024 - OWASP Top 10 for LLM Applications (2025) — LLM06 Excessive Agency, LLM01 Prompt Injection, LLM05 Improper Output Handling - OWASP Top 10 for LLM Applications (2025) — LLM06 Excessive Agency - OWASP Top 10 for LLM Applications (2025) — LLM05 Improper Output Handling - OWASP Top 10 for LLM Applications (2025) — LLM01 Prompt Injection - OWASP Top 10 for LLM Applications (2025) — LLM01 Prompt Injection, LLM05 Improper Output Handling - Lost in the Middle: How Language Models Use Long Contexts — Liu et al., 2023