--- title: "Die Tools, die ich jedem meiner Agenten gebe" description: "Fünf Keys, die ich in jeden Agenten einbinde: Linkup für die Websuche, Apify für Scraping, Softr für die Speicherung, Cloudflare für Deployments und OpenRouter für günstige Modell-Aufrufe. Wofür sie gut sind und welche Regeln ich dafür festgelegt habe." date: 2026-09-20 language: de canonical: https://gduv.club/de/articles/agent-toolbox source: gduv.club --- Claude Code, Codex, Dinge, die ich selbst geschrieben habe: In einer normalen Woche nutze ich drei oder vier davon, und das zugrunde liegende Modell ist meist das gleiche. Entscheidend dafür, ob eine Session erfolgreich ist, ist die Frage, worauf der Agent zugreifen kann. Deshalb binde ich überall die gleichen fünf Dinge ein: Suche, Daten, Storage, Deploys und günstige Modell-Aufrufe. Es ist egal, welcher Agent sie aufruft, und genau das ist der Punkt. Jedes Tool besteht aus einem Key in einer `.env`-Datei und einer Seite mit Notizen, anstatt dass ich alles für jedes Framework neu konfigurieren muss. ## Linkup, damit die Websuche nicht vom Framework abhängt Jeder Agent hat gewisse Web-Fähigkeiten, aber man weiß nie genau, wie diese funktionieren. Ruft er die Seite direkt oder eine gecachte Kopie ab? Folgt er dem gefundenen Link? Gibt er bei einem 403-Fehler stillschweigend auf und antwortet aus dem Gedächtnis? [Linkup](https://www.linkup.so) ist eine Search-API, die speziell für Modelle entwickelt wurde. Eine Abfrage, und Sie entscheiden über das Format der Antwort: - **Gerankte URLs**, wenn Sie die Quellen selbst auswählen möchten. - **Eine belegte Antwort**, wenn das Modell bereits mehrere Seiten gelesen hat und Sie das Fazit mit Zitaten benötigen. - **Strukturiertes JSON**, basierend auf einem übergebenen Schema. Letzteres nutze ich am häufigsten. Die Daten kommen als JSON an, sodass ein Skript sie direkt verarbeiten kann, anstatt dass ein Agent Prosa lesen und Felder manuell in eine Datei schreiben muss. Es gibt zudem einen Fetch-Endpunkt, der eine bekannte URL in etwa einer Sekunde in sauberes Markdown umwandelt, was die ehrlichste Version von "lies diese Seite" ist. Der Grund, warum dies besser ist als integrierte Tools, ist nicht die Qualität, sondern die Konsistenz. Egal, was ich heute Morgen geöffnet habe: Die Websuche funktioniert und verhält sich immer gleich. **Der Vorteil bei großen Datenmengen** Ein natives Web-Tool ist ein einziger Aufruf innerhalb einer Konversation, und die Antwort existiert nur dort. Ein Key bedeutet, dass ein Skript fünfzig Suchen parallel starten und in eine Datei schreiben kann, die der Agent dann liest. Die Recherche von 80 Unternehmen besteht dann nicht mehr aus 80 einzelnen Interaktionen. ## Apify, damit jede Plattform erreichbar ist [Apify](https://apify.com) ist ein Marktplatz für Scraper, und es gibt fast für alles einen. Meine eigenen LinkedIn-Posts mit den realen Zahlen, Videos eines YouTube-Kanals, die Kommentare darunter, Transkripte, Thumbnails, Stellenanzeigen. Ersteres nutze ich öfter als erwartet. Bei der Content-Planung ist es Gold wert, sagen zu können: "Hol mir die tatsächlichen Zahlen meiner letzten zwanzig Posts und sag mir, welche Hooks funktioniert haben". Das schlägt jedes Dashboard, weil die Antwort als Tabelle kommt, mit der ich dann weiterarbeiten kann. Nutzbar wird das Ganze durch Regeln, die in einer Skill-Datei stehen, welche der Agent liest, bevor er die API anspricht: - **Eine Tabelle zugelassener Scraper**, eine Zeile pro Plattform, mit Preis pro Ergebnis und einem von mir verifizierten Payload. Diese werden einfach ausgeführt, ohne Fragen. - **Nur Abrechnung pro Ergebnis.** Viele Scraper verlangen 25 $ im Monat im Voraus, was den Zweck zunichte macht, wenn man sie nur zweimal im Jahr braucht. Das ist ein harter Filter: Preismodell prüfen, und wenn es ein Abo ist, zum nächsten Scraper übergehen. - **Input-Schema lesen, Feldnamen nicht raten.** `maxItems` existiert im LinkedIn-Scraper nicht, dort heißt es `maxPosts`. Das durch einen fehlgeschlagenen Durchlauf herauszufinden, kostet Zeit und Ressourcen. - **Immer ein Limit setzen.** Eine Stichwortsuche ohne Limit kann tausende Zeilen zurückgeben und jede einzelne in Rechnung stellen. Das ist der einzige Fehler in diesem gesamten Setup, der echtes Geld kostet. Und für eine Plattform, die noch nicht in der Tabelle steht: 1. **Store durchsuchen**. Nur Abrechnung pro Ergebnis 2. **Input-Schema lesen**. Payload aus echten Feldern schreiben 3. **Drei an fünf Zeilen testen**. Vergleichen, was tatsächlich zurückkommt 4. **Gewinner skalieren**. Dann zur Tabelle hinzufügen _Den dritten Schritt lassen viele aus. Zwei Scraper für dieselbe Seite liefern völlig unterschiedliche Payloads, und der am besten bewertete ist oft nicht derjenige, dessen Struktur zu dem passt, was man gerade baut._ ## Softr, damit es einen Ort zum Speichern gibt Ein Agent, der Dinge findet, braucht einen Ort, um sie zu bewahren, und dieser Ort muss für mich ebenfalls zugänglich sein. Eine JSON-Datei auf der Festplatte scheitert daran: Niemand sortiert oder filtert eine Datei oder korrigiert darin eine einzelne Zelle. Ein Postgres mit vierzehn Tabellen, die ich nicht selbst entworfen habe, scheitert auf andere Weise. Eine [Softr](https://www.softr.io)-Datenbank liegt genau in der Mitte. Der Agent liest und schreibt über die API. Ich öffne dieselbe Tabelle im Browser, sortiere sie, filtere sie, korrigiere eine Zeile oder teile eine Ansicht mit jemandem, der sie ansehen muss. Letzteres ist der Teil, den viele vergessen, wenn sie einen Speicherort für einen Agenten wählen, aber es ist der Teil, den man am Ende täglich nutzt. Ich arbeite bei Softr, also berücksichtigen Sie das bei dieser Empfehlung. Der Grund, warum ich es trotzdem wählen würde, sind die Rate Limits, die für diese Art von Nutzung ungewöhnlich großzügig sind: **40 Reads und 30 Writes pro Sekunde, pro Token**. Ein Agent, der eine Liste durchläuft, erreicht diese Grenzen nie. Viele Projekte benötigen zudem überhaupt kein Interface. Es sind nur ich und die Daten, oder drei Personen und die Daten. Die Datenbank ist das Produkt, und ein Frontend dafür zu bauen, wäre Arbeit, nach der niemand gefragt hat. ## Cloudflare, damit aus einem Experiment eine URL wird Für alles, was nicht auf meinem Laptop bleiben soll. Ein Worker benötigt etwa eine Minute: genug für eine Seite, eine kleine API oder einen Agenten, den ich über HTTP mit deren SDK ausprobieren möchte. Weniger wichtig ist, was er tut, als wann es passiert. Ein Experiment, das in einer Minute online gehen kann, wird jemandem gezeigt; eines, das eine Deploy-Story benötigt, stirbt in dem Ordner, in dem es geboren wurde. ## OpenRouter, damit das große Modell nicht alles machen muss Der offensichtliche Grund ist der Zugriff auf jedes Modell über einen einzigen Key, und das stimmt zwar, ist aber nicht der Grund, warum es auf dieser Liste steht. Der eigentliche Grund ist, dass manche Aufgaben gar nicht innerhalb der Konversation des Agenten stattfinden sollten. Angenommen, Sie bereinigen 200 Zeilen. Wenn der Agent dies Schritt für Schritt macht, sind das 200 Turns in einem Kontext, der ständig wächst, wobei jeder Turn alles Vorherige mit dem teuersten Modell neu liest. Wenn er stattdessen ein Skript schreibt, das 200 kleine Aufrufe an ein günstiges Modell sendet, sieht jeder Aufruf nur eine Zeile, sie laufen parallel und das Ergebnis landet in einer Datei. **Was das Skript sendet** - Eine Zeile pro Aufruf - 200 Aufrufe gleichzeitig - Kein gemeinsamer Kontext **OpenRouter** - Ein Key, eine Rechnung - Modellwechsel per String - Fallbacks bei Ausfall **Was es erreicht** - Ein kleines, schnelles Modell - Ein Frontier-Modell bei Bedarf - Was auch immer letzte Woche erschien _Gleiche Arbeit, anderer Ort. Der Agent schreibt das Skript und liest das Ergebnis; er muss die 200 Zeilen nie im Kontext halten._ So teste ich auch Modelle, die ich noch nie benutzt habe. Einen String ändern, dasselbe Skript ausführen, mit dem vorherigen vergleichen. Das Konto und der Key bleiben gleich. ## Die Notizen sind genauso wichtig wie die Keys Nichts davon existiert nur in meinem Kopf, und nichts davon ist fest in einem Framework verbaut. Jedes Tool bekommt eine Skill-Datei: wie der Key heißt, welcher Endpunkt tatsächlich funktioniert, die Limits und die Fehler, die ich bereits gemacht habe. Die Datei für Apify enthält die Scraper-Tabelle. Die für Softr hält fest, dass `GET /fields` einen 405-Fehler zurückgibt und das Schema stattdessen vom Tables-Endpunkt kommt. Kleinigkeiten, aber ein Agent, der einen Endpunkt in jeder Session neu entdecken muss, wird ihn irgendwann falsch entdecken und Ihnen trotzdem sagen, dass es funktioniert hat. Ich habe vor einiger Zeit geschrieben, dass MCP-Server [der letzte Teil meines Setups waren, der noch wie ein Tool und nicht wie eine Datei geformt war](harness-agnostic-workspaces), weil jedes Framework sie separat konfigurieren muss und sie mit der Zeit auseinanderdriften. Ein Key in einer `.env`-Datei und eine Markdown-Datei daneben haben dieses Problem nicht. Jeder Agent, der eine Datei lesen und `curl` ausführen kann, hat das gesamte Toolkit, und der Wechsel zu einem neuen Agenten kostet nichts. ## Was ich noch nicht versucht habe [Monid](https://monid.ai) aggregiert Apify, Apollo und einige hundert andere Datenanbieter unter einem einzigen Guthaben, sodass man pro Aufruf zahlt, anstatt jedes Tool einzeln zu abonnieren. Sie beschreiben sich als das "OpenRouter für Agenten-Tools", was ziemlich genau das ist, was ich mir gewünscht habe. Ich brauchte es bisher nicht genug, um es gründlich zu testen, daher kann ich nicht sagen, ob es hält, was es verspricht. Es steht als Nächstes auf der Liste. Das ist das Setup. Fünf Keys und ein paar Seiten Notizen, und ich muss nicht mehr prüfen, ob der heutige Agent auf die Dinge zugreifen kann, die ich brauche.