TinyFish: 25 Fetch-Requests pro Minute machen Webdaten für KI-Agenten kostenlos testbar

Webzugriff ist 2026 keine nette Zusatzfunktion mehr, sondern die Infrastruktur-Entscheidung, die deinen Agenten entweder produktionsreif macht – oder zum Demo-Spielzeug degradiert. Wenn dein Agent für Research, Lead-Enrichment, Competitive Intelligence oder Monitoring arbeitet, lebt er von aktuellen Webdaten. Ohne stabile Search- und Fetch-Schicht operiert er auf altem Wissen und produziert im besten Fall „gute“ Antworten, die faktisch danebenliegen. Genau an dieser Stelle setzt TinyFish an: eine Search- und Fetch-API, die ausdrücklich für Agenten gebaut ist, inklusive kostenloser Nutzung, MCP-Setup und Output, der Token-Ballast konsequent wegschneidet.

Die harte Nachricht: Viele Teams unterschätzen Retrieval als Kosten- und Reliability-Treiber. Ein „irgendein SERP-Wrapper“ plus „irgendein HTML-Scraper“ klingt pragmatisch, skaliert aber schlecht, sobald du Tool-Loops, Latenz, Anti-Bot-Seiten, JavaScript-lastige SPAs und Tokenkosten zusammenrechnest. TinyFish verspricht hier eine agenten-native Alternative: Search unter api.search.tinyfish.ai liefert rank-stabiles, strukturiertes JSON, und Fetch unter api.fetch.tinyfish.ai rendert Seiten „real“ im Browser und gibt cleanes Markdown, JSON oder HTML zurück – fehlgeschlagene URLs werden nicht berechnet. Der Clou ist nicht das Rendering, sondern die Vorverarbeitung: TinyFish entfernt Skripte, Navigation, Ads und Cookie-Banner, bevor der Content dein Modell erreicht. Das senkt Tokens pro Seite und damit LLM-Kosten pro Call.

Der Einstieg ist bewusst frictionless: ein API-Key, keine Kreditkarte. Das Free-Tier-Limit liegt bei 5 Requests pro Minute für Search und 25 Requests pro Minute für Fetch. TinyFish nennt außerdem eine p50 Search-Latenz von unter 0,5 Sekunden. Für Tool-Loops ist das eine relevante Marke, weil du bei Mehrschritt-Agenten jede Sekunde mehrfach bezahlst – in Wartezeit, Kontextaufbau und Nutzerfrust. Wichtig ist auch die Produkt-Philosophie: Laut Quelle sind es dieselben Endpunkte, die auch Production-Workloads tragen, also kein kastriertes Demo-Backend.

Dieser Werkstatt-Artikel zeigt dir, wie du TinyFish in einen praxisnahen Workflow steckst: erst Search, dann Fetch, dann strukturierte Extraktion – ohne den typischen Token-Müll. Du bekommst Klick-Pfade für MCP/CLI, zwei copy-paste-Prompts für stabile Tool-Nutzung und eine Mini-ROI-Rechnung, die sich an typischen Knowledge-Work-Tasks orientiert. Neben TinyFish ordnen wir die Alternativen ein, die im selben Quellen-Text genannt werden: Tavily (Credits und Framework-Tiefe), Firecrawl (Crawl/Map/Agent-Endpoint, AGPL-3.0), Exa (semantischer Ansatz, MCP), Jina Reader (URL-Prefix, Limits bei Anti-Bot), Serper (SERP-only, billig) und Brave Search (unabhängiger Index, Enterprise-Privacy, kein Fetch).

Warum Search und Fetch getrennt denken: Tool-Loops, Tokenkosten, Reliability

Wenn du Agenten baust, ist „Webzugriff“ eigentlich zwei Probleme: (1) Finden, was relevant ist (Search), und (2) das Gefundene so holen, dass dein Modell damit arbeiten kann (Fetch). Viele Pipelines vermischen beides, etwa indem sie SERP-Snippets direkt in den Kontext schieben. Das bricht spätestens dann, wenn der Agent Quellen prüfen, Details extrahieren oder Zitate belegen soll. Dann brauchst du den Volltext, und der Volltext kommt selten sauber daher.

Die klassische Falle heißt Raw-HTML. Viele Fetch-Tools – und auch Fetch-Funktionen in manchen LLM-Clients – geben dir HTML inklusive Skripten, Menüs, Footern, Werbung, Cookie-Banner und Tracking-Pixeln. Für Menschen ist das „egal“, weil der Browser rendert und du selektiv liest. Für ein Sprachmodell ist das Token-Steuer: Du bezahlst Kontext für Elemente, die mit deinem Ziel nichts zu tun haben. Der Effekt potenziert sich, sobald du mehrere Seiten pro Aufgabe ziehst oder Crawler-Workflows fährst.

TinyFish positioniert sich exakt gegen diesen Token-Müll. Im Marktechpost-Artikel vom May 4, 2026 steht, dass TinyFish Fetch „scripts, navigation, ads, cookie banners“ entfernt, bevor der Content ins Modell geht. Das ist keine kosmetische Optimierung, sondern ein Architektur-Entscheid: Du verlegst „Boilerplate Removal“ weg vom Prompt („ignoriere Navigation…“) hin zur Retrieval-Schicht. Damit wird dein Agent nicht nur günstiger, sondern stabiler, weil weniger irrelevanter Text in den Kontext rutscht und Halluzinationen triggert.

Die zweite Reliability-Falle ist Rendering. Moderne Seiten sind oft SPAs, laden Inhalte asynchron nach oder blocken Headless-Scraper. TinyFish schreibt, Fetch mache ein „real full-browser render“ und kommt auch mit „JavaScript-heavy SPAs, dynamic content, and anti-bot pages“ klar. Das ist in der Praxis entscheidend, weil du sonst an genau den Seiten scheiterst, die du bei Research oder Competitive Intelligence brauchst: Produktseiten mit Interaktions-Content, Pricing-Komponenten, Dokumentation mit clientseitigem Routing.

Die dritte Falle heißt Latenz im Tool-Loop. Ein Agent, der iterativ arbeitet, führt Search und Fetch nicht einmal, sondern mehrfach aus: Suchanfrage → Kandidatenliste → Fetch von 2–5 URLs → zweite Suchanfrage, weil eine Quelle fehlt → weiterer Fetch. TinyFish nennt eine p50 Search-Latenz „under 0.5 seconds“. Das ist keine Garantie für deine spezielle Query, aber ein brauchbarer Zielwert: Unterhalb dieser Größenordnung kannst du Search in den Loop legen, ohne dass sich die UI wie ein Fernschreiber anfühlt.

Und dann ist da noch die „Plattform-Reife“: Viele Tools haben einen kostenlosen Playground, aber die produktiven Endpunkte unterscheiden sich oder werden gedrosselt. TinyFish betont laut Quelle das Gegenteil: „these are the same endpoints powering production agent workloads — not a degraded demo tier“ und „no code changes required“, wenn du aus dem Free-Plan herauswächst. Für dich bedeutet das: Du kannst den Workflow im Team testen, ohne später alles umzubauen.

Tool-Check: TinyFish vs. Tavily, Firecrawl, Exa, Jina, Serper, Brave

Du musst TinyFish nicht „blind“ wählen. Der Originaltext listet mehrere Alternativen, die sich in ihrem Retrieval-Modell klar unterscheiden. Wichtig: Das ist kein Beauty-Contest, sondern eine Frage deiner Workload. Willst du rank-stabile JSON-Suche? Willst du semantische Ähnlichkeit statt Keyword-Freshness? Willst du Crawl/Map im Paket? Oder brauchst du nur billige SERP-Daten und baust den Rest selbst?

TinyFish deckt Search und Fetch in einem Stack ab. Das Free-Tier ist klar definiert: Search 5 requests/minute, Fetch 25 requests/minute, ein API-Key, keine Kreditkarte. Fetch rendert im Browser und liefert cleanes Markdown/JSON/HTML; failed URLs sind free. Dazu kommt ein „agent-native“ Surface: REST, MCP-Konfig als „single JSON config drop-in“, CLI, „agent Skill“ als Einzeiler sowie Python/TypeScript SDKs. Integrationen nennt der Text für Claude Code, OpenClaw, Hermes Agent (Nous Research), Cline, Cursor, Codex, LangChain, CrewAI, plus n8n, Dify und Vercel Skills.

Tavily ist im Originaltext als „real-time search engine built specifically for AI agents and RAG workflows“ beschrieben. Der Researcher-Plan ist free und beinhaltet „1,000 API credits per month“. Bezahlte Pläne: „Project at $30/month (4,000 credits), Bootstrap at $100/month (15,000 credits), and Startup at $220/month (38,000 credits)“; Pay-as-you-go: „$0.008 per credit“. Credits resetten monatlich und rollen nicht über. Für die Praxis wichtig ist die Notiz im Text, dass „Nebius announced an agreement to acquire Tavily in February 2026“, was bei manchen Teams Fragen zu Pricing-Stabilität und Roadmap aufwirft. Das ist weniger Technik als Risiko-Management: Wenn du Retrieval als Kern-Infrastruktur siehst, willst du Ownership- und Preisdynamiken im Blick behalten.

Firecrawl adressiert den „URL in LLM-ready Markdown/JSON“-Use-Case und bietet zusätzlich Interaktions- und Crawl-Funktionen. Der Originaltext nennt Media-Parsing (PDF/DOCX), Click/Scroll/Interact vor der Extraktion, und vier Modi: Scrape, Crawl, Map, Agent-Endpoint. Free gibt „500 one-time credits“, paid startet bei „$16/month (Hobby, 3,000 credits/month)“ bis „$83/month (Standard, 100,000 credits/month on annual billing)“. Credits rollen nicht. Der rechtliche Punkt: Firecrawl ist „open source under AGPL-3.0“. Das ist für Self-Hosting und Datenhoheit relevant, aber AGPL kann für proprietäre Produkte eine Compliance-Diskussion auslösen, wenn du es in deine Server-Software integrierst.

Exa steht im Text für semantische Suche via „neural embeddings“, nicht Keyword-Matching. Als Signal nennt der Artikel: „Cursor uses Exa to power its @web feature.“ Pricing laut Text: Free tier „up to 1,000 requests per month“, Search-with-contents „$7 per 1,000 requests“, und Text-Content/Highlights sind im Base-Request bis „up to 10 results per request“ enthalten. Exa liefert auch einen offiziellen MCP-Server, inklusive Support für Claude Desktop/Code, VS Code, Windsurf und Gemini CLI. Für dich heißt das: Exa passt gut, wenn du in Themen-Clustern suchst und semantische Nähe wichtiger ist als nur „neuester Treffer“.

Jina AI Reader ist der Low-Friction-Hack: Du setzt einfach „https://r.jina.ai/“ vor eine URL, Search geht über „https://s.jina.ai/“. Basic usage ist free, kein API-Key. Für höhere Rate Limits brauchst du einen Key, und dann rechnet Jina „based on content length rather than per-request“. Neue Keys enthalten „10,000,000 free tokens on signup“. Der Haken steht ebenfalls im Text: Jina umgeht keine Anti-Bot-Systeme und gibt einen Error, wenn geblockt. Außerdem ist Reader nicht so tief in Agent-Frameworks integriert wie Tavily/Firecrawl/Exa. Und: Der Search-Endpoint holt die „top five results in full“ statt konfigurierbarer Listen. Wenn du schnelle Einzelseiten brauchst, ist Jina unschlagbar simpel. Wenn du robust gegen Blocks sein musst, wird es schwierig.

Serper ist eine SERP-only API für Google. Preis laut Text: „$1 per 1,000 queries“ im Starter, bis „$0.30 per 1,000“ bei höherem Volumen. Neue Accounts bekommen „2,500 free queries“ ohne Kreditkarte. Serper liefert strukturiertes JSON inklusive Knowledge Graphs und Answer Boxes, macht aber kein Fetch/Content-Extraction. Der Originaltext nennt als Praxis-Architektur: Serper für Search plus Jina Reader oder TinyFish Fetch für Retrieval. Das ist ein typischer „Best-of-Breed“-Stack, wenn Kosten pro Query extrem wichtig sind.

Brave Search API hat einen unabhängigen Index mit „over 40 billion pages“ und keine Google/Bing-Dependency. Für Privacy/Compliance relevant: „Zero Data Retention“ für Enterprise. Brave hat einen offiziellen MCP-Server und unterstützt verschiedene Suchtypen (web, local business, image, video, news). Gleichzeitig hat Brave laut Text das Free-Tier für neue Nutzer entfernt: Stattdessen bekommen neue Nutzer „$5 in monthly credits — roughly 1,000 queries“, danach werden „$5 per 1,000 requests“ berechnet. Bestehende Nutzer auf dem alten Plan bleiben „grandfathered“. Brave ist search-only, kein fetch. Wenn du Index-Unabhängigkeit als harte Anforderung hast, ist Brave einer der wenigen klaren Kandidaten.

So setzt du es um

1. Definiere deinen Retrieval-Job in zwei Tools: Search → Fetch.
   Aktion: Lege fest, dass dein Agent nie „aus dem Bauch“ antwortet, wenn Fakten aus dem Web kommen sollen. Er muss erst suchen, dann gezielt 1–3 Seiten fetchen.
   Ergebnis: Du bekommst nachvollziehbare Quellenketten und vermeidest, dass der Agent auf Snippets overfittet.
   Klick-Pfad: In deinem Agent-Framework „Tools“ aktivieren → zwei Tools registrieren: Search-Endpoint und Fetch-Endpoint.

2. Erstelle einen TinyFish API-Key und starte im Free-Tier.
   Aktion: Besorge dir den API-Key (keine Kreditkarte laut Originaltext) und setze ihn als Secret in deinem Projekt.
   Ergebnis: Du kannst sofort mit 5 Search-Requests/Minute und 25 Fetch-Requests/Minute testen.
   Klick-Pfad: TinyFish Dashboard → API Keys → Create Key → Copy → in .env als TINYFISH_API_KEY speichern.

3. Baue den minimalen Search-Call und speichere das JSON statt es ins Kontextfenster zu kippen.
   Aktion: Lass Search rank-stabiles, strukturiertes JSON liefern und speichere es als Datei oder in deinem Agent-State.
   Ergebnis: Du reduzierst Tokenverbrauch, weil du die Rohdaten nicht komplett in den Prompt drückst.
   Klick-Pfad: CLI installieren → Terminal: npm install -g @tiny-fish/cli → dann Search ausführen und Output in eine Datei schreiben (TinyFish CLI schreibt laut Text direkt ins Filesystem).

4. Fetch nur die Top-URLs und wähle cleanes Markdown als Default-Format.
   Aktion: Nimm 2–3 URLs aus dem Search-Result und rufe Fetch mit „clean markdown“ ab.
   Ergebnis: Du bekommst LLM-ready Content ohne Scripts/Ads/Cookie-Banner und senkst Tokenkosten pro Seite.
   Klick-Pfad: Agent Tool Call → Fetch → Response Format: markdown (oder JSON/HTML, wenn du strukturierte Extraktion brauchst).

5. Nutze MCP, wenn du in einem MCP-aware Client arbeitest.
   Aktion: Hinterlege die MCP-Konfiguration als JSON „drop-in“ (so nennt es der Originaltext) für deinen Client.
   Ergebnis: Dein Client kann TinyFish als Tool standardisiert ansprechen; du sparst Integrationsarbeit pro Projekt.
   Klick-Pfad: Client → Settings → Tools/MCP → Add Server → JSON Config einfügen → speichern → Tool testen.

6. Installiere die TinyFish Skill, damit dein Coding-Agent Search vs. Fetch korrekt einsetzt.
   Aktion: Installiere die Skill über den Einzeiler aus dem Originaltext: npx skills add github.com/tinyfish-io/tinyfish-cookbook –skill tinyfish.
   Ergebnis: Der Agent lernt, wann Search reicht und wann Fetch nötig ist, und ruft Tools konsistenter auf.
   Klick-Pfad: Terminal im Projekt → Befehl ausführen → Agent neu starten → Skill in der Tool-Liste prüfen.

Prompt-Lab: Zwei copy-paste Prompts für stabilen Retrieval-Output

Die meisten Retrieval-Probleme sind keine API-Probleme, sondern Prompt-Hygiene. Du brauchst klare Tool-Regeln, sonst „vergisst“ der Agent Fetch, zieht zu viele Seiten oder kippt Rohdaten in den Kontext. Hier sind zwei Prompts, die in der Praxis zuverlässig sind, weil sie Rolle, Aufgabe und Output-Format sauber trennen. Du kannst sie in jedem Agent-Setup verwenden, das Tools aufrufen kann.

ROLE: Du bist ein Research-Agent für Business-Entscheidungen. Du darfst nur Aussagen treffen, die du aus aktuellen Webquellen ableitest, die du in dieser Session gesucht und gefetcht hast.

KONTEXT: Du hast zwei Tools:
1) SEARCH: liefert strukturierte JSON-Suchergebnisse.
2) FETCH: rendert eine URL im Browser und liefert cleanes Markdown/JSON/HTML.

AUFGABE:
- Starte mit SEARCH für die Nutzerfrage.
- Wähle maximal 3 URLs aus (Priorität: offizielle Herstellerseiten, technische Doku, Preis-/Plan-Seiten).
- Hole jede URL mit FETCH als Markdown.
- Extrahiere aus jedem Dokument: Kernaussage, konkrete Limits/Preise/Rate-Limits, relevante Einschränkungen.

OUTPUT-FORMAT:
Gib mir exakt:
1) Ein Kurzfazit (max. 5 Sätze)
2) Eine Liste der 3 Quellen als URL
3) Pro Quelle 3 Bulletpoints mit Fakten

REGELN:
- Keine Zitate in Anführungszeichen.
- Wenn eine Quelle bei FETCH fehlschlägt: nenne sie und ersetze sie durch eine neue URL via SEARCH.
- Wenn du keine belastbare Quelle findest: sage das klar und stoppe.

ROLE: Du bist ein Agent, der Web-Retrieval token-effizient macht.

KONTEXT:
- Du bekommst von SEARCH eine Liste mit Treffern.
- Du bekommst von FETCH den cleanen Seiteninhalt.

AUFGABE:
- Suche zuerst nach 6–10 Treffern.
- Bewerte jeden Treffer nach: (a) Relevanz zur Frage, (b) erwartete „Token-Dichte“ (wie viel Inhalt vs. Boilerplate), (c) Wahrscheinlichkeit von Anti-Bot.
- Fetche nur die besten 2 URLs.
- Fasse den Inhalt in einem strukturierten Ergebnis zusammen.

OUTPUT-FORMAT (JSON):
{
  "selected_urls": ["...", "..."],
  "why_selected": {"url": "..."},
  "facts": [
    {"fact": "...", "source_url": "..."}
  ],
  "open_questions": ["..."]
}

REGELN:
- Keine weiteren URLs im Output außer den zwei ausgewählten.
- Wenn FETCH durch Anti-Bot scheitert: nutze SEARCH erneut und wähle eine alternative Quelle.

Heißt im Alltag: Du bekommst weniger „Tool-Spam“ und mehr deterministischen Output. Und ja, das spart Zeit: Wenn du pro Research-Task heute typischerweise 15 Minuten in „Quellen finden, öffnen, kopieren, reinigen“ investierst, drückst du das mit sauberem Search→Fetch→Extraktion oft auf rund 8–10 Minuten. Bei fünf Tasks pro Woche sind das ca. 25–35 Minuten pro Woche, ohne dass du dein Modell größer drehen musst.

Was sich rechnet

ROI bei Retrieval ist tricky, weil du nicht nur API-Kosten, sondern Tokenkosten, Wartezeit und Fehlentscheidungen durch stale data bewertest. Ich halte es hier bewusst simpel und nutze nur Zahlen, die wir aus dem Originaltext sicher haben: TinyFish ist im Free-Tier nutzbar mit 5 Search-Requests/Minute und 25 Fetch-Requests/Minute, Tavily/Firecrawl/Exa/Serper/Brave haben klar definierte Preis- oder Credit-Modelle, und TinyFish reduziert Tokens durch Content-Cleaning.

Mini-Szenario: „Wettbewerbscheck“ für ein Sales-Deck
Vorher (manuell): 1 Stunde Recherche (Suche, 6 Tabs, Copy/Paste, Cleanup, kurze Zusammenfassung). Interner Kostensatz: 80 € pro Stunde. Ergebnis: 80 €.
Nachher (Agent mit TinyFish Search+Fetch): 15 Minuten Setup und Lauf (Search, Fetch von 3 Seiten, strukturierte Facts). Interner Kostensatz: 80 € pro Stunde → 20 €.

API-Kosten: Wenn du im Free-Tier bleibst, ist TinyFish für diesen Task kostenfrei nutzbar. Das Free-Tier reicht für typische Runs, weil du in 15 Minuten bei 5 Search-Requests/Minute theoretisch 75 Searches hast, und bei 25 Fetch-Requests/Minute 375 Fetches. Du brauchst realistisch einen Bruchteil davon. Der echte Kostentreiber verschiebt sich damit in Richtung LLM-Tokens – und genau da setzt TinyFish Fetch an, indem es Raw-HTML-Ballast entfernt.

Im Klartext: 80 € → 20 € ist ein 4×-Hebel pro Task. Wenn du das zweimal pro Woche machst, sind das 120 € pro Woche. Auf Monatsbasis (vier Wochen) sind das 480 €. Klingt nach viel – ist es auch, sobald du Retrieval als Standardprozess etablierst. Und das ist nur die Zeit. Der zweite ROI-Kanal ist „Fehlervermeidung“: Aktuelle Preise, Limits oder Produktfeatures falsch zu kommunizieren kostet dich Deals und Vertrauen. Diesen Schaden kannst du selten sauber beziffern, aber er ist real.

Wann Tavily/Exa/Firecrawl finanziell besser sind
Wenn du jeden Tag Dutzende Research-Jobs fährst, kann ein planbares Credit-Modell einfacher zu budgetieren sein. Tavily hat laut Originaltext klare Monatspläne bis $220/month und Pay-as-you-go $0.008 per credit. Exa kostet $7 per 1,000 requests für Search-with-contents. Firecrawl startet bei $16/month. Für größere Teams kann das „Accounting-freundlicher“ sein als „free tier + später upgraden“, solange du die Credit-Reset-Logik (nicht roll-over) in dein Monitoring einbaust.

Die typischen Fallstricke

• Fehler 1: Du fetcht zu viel und überflutest dein Modell.
  Symptom: Der Agent zieht 10+ Seiten, das Modell wird teuer und unpräzise.
  Lösung: Hartes Limit im Prompt („maximal 3 URLs“) und ein Auswahl-Scoring (Relevanz, Token-Dichte, Anti-Bot-Risiko). Nutze TinyFish Search für die Kandidatenliste und Fetch nur für die Top-Quellen.

• Fehler 2: Du verlässt dich auf Search-Snippets und übersiehst Details.
  Symptom: Der Agent behauptet etwas, das nur im Snippet angedeutet wird, aber im Volltext anders steht.
  Lösung: Policy: Keine Fakt-Aussage ohne Fetch. Search dient nur zur Auswahl, Fetch liefert die Belege.

• Fehler 3: Anti-Bot-Blocks brechen deinen Workflow still.
  Symptom: Der Agent liefert leere Extrakte oder hängt, ohne dass du es merkst.
  Lösung: Error-Handling im Agenten: Wenn Fetch fehlschlägt, wird das laut Prompt klar gemeldet und via Search eine Alternative gesucht. TinyFish sagt im Originaltext, es kann auch „anti-bot pages“ rendern; Jina Reader dagegen nicht. Plane das bewusst ein.

• Fehler 4: Lizenz- und Compliance-Themen werden erst nach dem PoC diskutiert.
  Symptom: Du baust auf ein Tool, dann blockt Legal die Nutzung oder verlangt Re-Engineering.
  Lösung: Prüfe bei Firecrawl früh die AGPL-3.0-Implikation für dein Deployment. Bei Brave ist „Zero Data Retention“ ein Enterprise-Feature; kläre früh, ob du das brauchst. Bei DACH-Setups mit personenbezogenen Daten musst du DSGVO sauber denken: Wer verarbeitet was, wo liegen Logs, wie sieht der Drittlandtransfer aus?

Was bedeutet das für den EU AI Act?

Wenn du Retrieval-APIs in Agenten einbaust, baust du eine Datenpipeline, die Inhalte aus dem offenen Web in deine KI-gestützten Entscheidungen zieht. Seit Feb 2025 gilt im EU AI Act die KI-Literacy-Pflicht, und seit Aug 2025 sind GPAI-Regeln, Governance und Strafen in Kraft. Für dich heißt das operativ: Du musst nicht nur das Modell „im Griff“ haben, sondern auch die Toolchain, die das Modell füttert. Retrieval ist Teil des Systems.

Praktisch sind drei Punkte relevant. Erstens: Nachvollziehbarkeit. Wenn dein Agent für Kunden oder interne Entscheider recherchiert, brauchst du reproduzierbare Quellenketten. Ein Search→Fetch-Workflow mit gespeicherten JSON-Resultaten und cleanem Fetch-Output macht Audits leichter als „Copy/Paste aus dem Browser“. Zweitens: Risiko von verbotenen oder problematischen Inhalten. Retrieval kann dir Inhalte in den Kontext ziehen, die du nicht erwartet hast. Du brauchst Filterregeln (Domains, Content-Kategorien) und ein Logging, das du datenschutzkonform betreibst. Drittens: Verantwortlichkeit. Je autonomer dein Agent agiert, desto wichtiger wird ein klares Betriebsmodell: Wer überwacht, wer genehmigt, wer dokumentiert?

So What? Retrieval wird zur Kostenstelle, die du aktiv designen musst

Was heißt das für dich als Knowledge Worker, Creator oder Entscheider in DACH? Kurz gesagt: Wenn du Agenten ernsthaft einsetzt, ist Retrieval nicht „nur ein Plugin“, sondern eine Kostenstelle und ein Risikohebel. Du kannst beides steuern, wenn du die Architektur sauber aufsetzt: Search als Auswahl, Fetch als Beleg, Preprocessing als Token-Schutzschicht, und klare Tool-Regeln im Prompt.

TinyFish ist dafür ein spannender Baustein, weil es drei Dinge kombiniert, die im Alltag zählen: ein kostenloses Tier ohne Kreditkarte, klare Rate Limits (5/min Search, 25/min Fetch) und token-effizienten Output durch Cleaning. Dazu kommt MCP als Standard-Integrationsweg. Das reduziert Projektfriktion, weil du Retrieval nicht in jedem Tool neu verkabelst. Wenn du in Teams arbeitest, ist genau das der Unterschied zwischen „wir testen mal KI“ und „wir bauen eine wiederholbare Pipeline“.

Gleichzeitig solltest du TinyFish nicht isoliert betrachten. Die Alternativen im Originaltext zeigen, dass du je nach Use-Case modular bauen kannst: Serper für billige SERPs plus TinyFish Fetch oder Jina Reader als Fetch-Layer. Exa, wenn semantische Suche in Code- oder Research-Kontexten dominiert. Firecrawl, wenn du Crawl/Map und Interaktionsschritte brauchst oder Open-Source als Grundsatzforderung hast. Brave, wenn Index-Unabhängigkeit und Privacy harte Kriterien sind.

Meine Empfehlung für einen pragmatischen Start in DACH: Bau einen kleinen „Retrieval-Playbook“-Workflow, den du in zwei Stunden mit deinem Team testen kannst. Nimm zwei typische Aufgaben (z. B. Wettbewerbscheck und Policy-Recherche), definiere die Tool-Regeln, logge die Quellen und miss zwei Werte: Zeit pro Task und Tokens pro Task. Wenn du damit nicht mindestens ca. 25 Minuten pro Woche sparst, liegt das fast immer an fehlenden Limits oder daran, dass du zu viele Seiten fetcht. Fix das zuerst, bevor du über größere Modelle oder mehr Agenten nachdenkst.

Fazit: TinyFish senkt die Einstiegshürde – aber du musst Retrieval als System behandeln

TinyFish liefert 2026 genau die Art Retrieval-Infrastruktur, die Agenten von „beeindruckend“ zu „verlässlich“ schiebt: rank-stabiles JSON bei Search, echtes Browser-Rendering bei Fetch, und vor allem saubere Outputs, die Tokenkosten nicht explodieren lassen. Das Free-Tier mit 5 Search-Requests/Minute und 25 Fetch-Requests/Minute ist groß genug, um echte Workflows zu testen, ohne Procurement, ohne Kreditkarte, ohne Vertragsgespräche. Wenn du in MCP-aware Clients arbeitest, ist der Integrationsaufwand laut Originaltext niedrig, weil eine JSON-Konfiguration reicht.

Der Haken ist nicht TinyFish, sondern deine eigene Disziplin: Retrieval wird nur dann günstig und stabil, wenn du Limits setzt, Fehler sauber behandelst und Ergebnisse außerhalb des Kontextfensters speicherst. Sobald du das tust, ist der ROI schnell sichtbar – nicht weil das Tool magisch ist, sondern weil du Copy/Paste, Tab-Chaos und Token-Müll eliminierst.

Meine Prognose für die kommenden Jahre: Search- und Fetch-APIs werden sich weiter in Richtung „agent-native“ Standardschichten bewegen, mit MCP-ähnlichen Integrationspfaden, Skills/Policies für Tool-Auswahl und stärkerer Vorverarbeitung. Teams, die Retrieval heute als eigene Komponente designen, werden ihre Agenten billiger betreiben und leichter auditieren. Teams, die Retrieval als Nebenbei-Detail behandeln, zahlen doppelt: erst in Tokens, dann in falschen Entscheidungen.