429 Rate Limited bei MCP: Weniger Tool-Aufrufe und sicheres Retry

429 Rate-Limit-Fehler vom MCP-Server? Diese Anleitung hilft, Rate Limiting zu verstehen, Ursachen zu finden (Bursts, Schleifen, große Listen), sicheres Retry/Backoff umzusetzen und Tool-Aufrufe durch Batching- und Paginierungsmuster zu reduzieren.

429 Rate Limits verstehen

Ein 429-Statuscode bedeutet, dass Sie das Rate-Limit überschritten haben – zu viele Anfragen in zu kurzer Zeit. Der Server lehnt vorübergehend Anfragen ab, um sich zu schützen und faire Nutzung sicherzustellen.

Was Rate Limiting bedeutet

• Rate-Limit: Maximale Anzahl erlaubter Anfragen pro Zeitfenster
• 429-Fehler: Server-Antwort, die überschrittenes Limit anzeigt
• Vorübergehend: Setzt sich meist nach kurzer Zeit zurück (Sekunden bis Minuten)
• Schützend: Verhindert Serverüberlastung und sorgt für faire Nutzung

Häufige Ursachen für Rate Limiting

1. Bursting (zu viele Aufrufe auf einmal)

Symptom

Viele Tool-Aufrufe in schneller Folge

Beispiel

"List all my projects, then for each project list all tasks, then for each task get details"

Kann in Sekunden hunderte Aufrufe auslösen.

2. Schleifen ohne Verzögerungen

Symptom

Wiederholte Tool-Aufrufe in einer Schleife ohne Rate-Begrenzung

Beispiel

"Update 100 tasks one by one" (ohne Batching oder Verzögerungen)

Jedes Update ist ein eigener Aufruf und trifft schnell auf Limits.

3. Große Listen ohne Paginierung

Symptom

Alle Elemente auf einmal abrufen statt in paginierten Batches

Beispiel

"Get all my tasks" (kann 1000+ Aufgaben liefern, viele Aufrufe nötig)

Paginierung nutzen, um in kleineren Batches abzurufen.

4. Parallele Tool-Aufrufe

Symptom

Mehrere Tool-Aufrufe gleichzeitig

Beispiel

"Get details for tasks 1, 2, 3, 4, 5 all at the same time"

Parallele Aufrufe können Rate-Limits schnell ausschöpfen.

Schritt 1: Rate-Limit-Fehler erkennen

Erkennen, wann Sie auf Rate-Limits stoßen:

429-Fehler-Anzeichen

• HTTP-Statuscode: 429 Too Many Requests
• Fehlermeldung mit "rate limit" oder "too many requests"
• Response-Header können Retry-After enthalten (Sekunden bis zum Warten)
• Einige Aufrufe gelingen, dann schlagen plötzlich alle fehl
• Fehler treten nach einer Welle erfolgreicher Aufrufe auf

Rate-Limit vs. andere Fehler

Schritt 2: Sicheres Retry mit Backoff umsetzen

Bei 429: Retry mit exponentiellem Backoff:

Exponentielle-Backoff-Strategie

Empfohlenes Retry-Muster

1. Erster Retry: 1–2 Sekunden warten, dann erneut versuchen
2. Zweiter Retry: 2–4 Sekunden warten, dann erneut versuchen
3. Dritter Retry: 4–8 Sekunden warten, dann erneut versuchen
4. Max. Retries: Insgesamt 3 Versuche
5. Danach: Fehler dem Nutzer melden

Retry-After-Header prüfen

Manche Server senden einen Retry-After-Header mit der Wartezeit in Sekunden:

• Wenn vorhanden, mindestens so viele Sekunden warten
• Wenn nicht vorhanden, exponentielle Backoff (1s, 2s, 4s)
• Nicht sofort erneut versuchen – verschlimmert das Problem

Prompt-Muster für Retries

Gut: Explizite Retry-Anweisung

"If a tool call returns 429 rate limit error, wait 2 seconds and retry once. If it still fails, wait 4 seconds and retry again. After 3 attempts, report the error."

So wird die KI angeleitet, Backoff korrekt umzusetzen.

Schritt 3: Tool-Aufrufe durch Batching reduzieren

Operationen in Batches ausführen, um die Anzahl der Aufrufe zu verringern:

Batching-Strategie

Batch-Operationen

1. Elemente einmal auflisten (mit Paginierung bei Bedarf)
2. In Batches von 10–20 verarbeiten
3. Auf Abschluss des Batches warten, bevor das nächste kommt
4. Parallele Aufrufe innerhalb von Batches vermeiden

Beispiel: Batch-Update-Muster

Gut: Batch-Updates

"Update task titles in batches of 10:
1. Get first 10 tasks
2. Update each one sequentially
3. Wait for all 10 to complete
4. Then get next 10 tasks
5. Repeat until done"

Reduziert Aufrufe und vermeidet Rate-Limits.

Schlecht: Ungebatchte Updates

"Update all 100 tasks at once"

Löst schnell 100+ Aufrufe aus und trifft auf Rate-Limits.

Schritt 4: Paginierung nutzen

Große Listen in kleineren, paginierten Teilen abrufen:

Paginierungs-Best-Practices

Paginierte Anfragen

// Statt alle Aufgaben zu holen
list_tasks()  // Kann 1000+ Aufgaben liefern, viele Aufrufe

// Paginierung nutzen
list_tasks(limit: 50, offset: 0)   // Erste 50
list_tasks(limit: 50, offset: 50)  // Nächste 50
// Bis fertig

Empfohlene Limits

• list_tasks: limit: 50–100 pro Aufruf
• list_task_comments: limit: 25–50 pro Aufruf
• list_projects: Meist klein, bei Bedarf limit: 20

Prompt-Muster für Paginierung

Gut: Paginierte Anfrage

"List my tasks, but only show the first 50. If I need more, I'll ask for the next batch."

So nutzt die KI Paginierung.

Schritt 5: Parallele Aufrufe vermeiden

Tool-Aufrufe wenn möglich sequenziell ausführen:

Sequenziell vs. parallel

Gut: Sequenzielle Aufrufe

"First, list my projects. Then, for each project, list the tasks one at a time."

Fördert sequenzielle statt parallele Aufrufe.

Schlecht: Parallele Aufrufe

"Get all my projects and all their tasks at once"

Kann parallele Aufrufe auslösen und schnell auf Rate-Limits stoßen.

Schritt 6: Filter nutzen, um Ergebnisse einzugrenzen

Vor dem Abruf filtern, um die Anzahl der zurückgegebenen Elemente zu reduzieren:

Gefilterte Abfragen

Filter nutzen

// Nur diese Woche fällige Aufgaben
list_tasks(due_date: "2026-06-12", status: "in_progress", limit: 50)

// Statt alle Aufgaben zu holen und clientseitig zu filtern
list_tasks()  // Liefert alles, dann Filter (mehr Aufrufe)

Verfügbare Filter

• project_id: Nach bestimmten Projekt filtern
• board_id: Nach bestimmten Board filtern
• status: Nach Status filtern (open, in_progress, done, blocked)
• due_date: Nach Fälligkeitsdatum filtern
• keyword: Nach Stichwort suchen (serverseitige Filterung)

Schritt 7: Überwachen und anpassen

Tool-Aufruf-Muster beobachten, um künftige Rate-Limits zu vermeiden:

Rate-Limit-Vermeidungs-Checkliste

• ✅ Paginierung für List-Operationen (limit-Parameter)
• ✅ Filter nutzen, um Ergebnisse vor dem Abruf einzugrenzen
• ✅ Operationen in Batches (10–20 Elemente pro Batch)
• ✅ Sequenzielle statt parallele Aufrufe
• ✅ Retry mit exponentiellem Backoff umgesetzt
• ✅ Retry-After-Header prüfen, wenn vorhanden
• ✅ Gesamtzahl der Aufrufe pro Workflow begrenzen

Schnell-Checkliste

Bei 429-Fehlern

1. ✅ Fehler als 429 erkannt (Rate-Limit, nicht Auth/Berechtigung)
2. ✅ Response auf Retry-After-Header geprüft
3. ✅ Exponentielles Backoff (1s, 2s, 4s Verzögerungen) umgesetzt
4. ✅ Retries auf maximal 3 Versuche begrenzt
5. ✅ Workflow auf Batching-Möglichkeiten geprüft
6. ✅ Paginierung für große List-Operationen ergänzt
7. ✅ Parallele Tool-Aufrufe reduziert
8. ✅ Filter zur Eingrenzung der Ergebnisse ergänzt

Verwandte Fehlerbehebung

• Timeouts – Timeout-Probleme beheben, die mit Rate-Limits auftreten können
• Paginierungs-Anleitung – Paginierungsmuster für MCP-Tools
• Batching-Anleitung – Tool-Aufrufe effektiv batchen
• Fehlerbehebungs-Übersicht – Alle Fehlerbehebungsanleitungen durchsuchen