MCP-Timeouts: Langsame Antworten erkennen und beheben
MCP-Timeout-Fehler durch langsames Netz, große Payloads oder Rate-Limits beheben. Paginierung, Batching und Verbindungsoptimierung für schnellere MCP-Workflows.
Was sind Timeout-Fehler?
Ein Timeout entsteht, wenn eine MCP-Operation länger dauert als das konfigurierte Timeout des Clients (oft 30–60 Sekunden). Die Anfrage wird abgebrochen und Sie sehen einen Fehler.
Typische Timeout-Symptome
- Anfrage hängt und schlägt schließlich fehl
- Fehlermeldung: „Request timeout“ oder „Connection timeout“
- Operation dauert länger als 30–60 Sekunden
- Kleine Abfragen funktionieren, große schlagen fehl
Häufige Ursachen
1. Große Ergebnismengen
Zu viele Aufgaben auf einmal überlasten die Verbindung:
Problem
list_tasks ohne Filter liefert 1000+ Aufgaben und verursacht Timeout.
Lösung: Paginierung nutzen
Ergebnisse pro Anfrage begrenzen und seitenweise abrufen:
// Statt alle Aufgaben auf einmal
list_tasks(limit=50, page=1) // Erste 50
list_tasks(limit=50, page=2) // Nächste 502. Langsame Netzverbindung
Schlechte Internetverbindung verursacht Verzögerungen:
Diagnose-Schritte
- Netzgeschwindigkeit testen (Speed-Test)
- Latenz prüfen: Ping zu api.corcava.com
- Kleinere Abfragen testen: Wenn kleine klappen und große nicht, eher Bandbreite
Lösungen
- VPN: VPN erhöht Latenz – direkte Verbindung testen
- Ergebnismenge reduzieren: Filter und Paginierung
- Retry mit Backoff: Exponentielles Backoff bei Wiederholungen
3. Rate Limiting
Zu viele Anfragen in kurzer Zeit können Rate-Limits auslösen:
Symptome
- Anfragen starten schnell, werden dann langsamer
- 429 Rate Limited Fehler erscheinen
- Erste Anfragen erfolgreich, danach Timeout
Lösung
Siehe Rate-Limit-Fehlerbehebung.
4. Komplexe Abfragen
Operationen mit aufwändiger Verarbeitung dauern länger:
Langsame Operationen
- Projektübergreifend: Suche über 10+ Projekte
- Große Zeiträume: Aufgaben der letzten 2 Jahre
- Ungefilterte Listen: Alle Aufgaben ohne Filter
Optimierung
- Filter setzen: status, project_id, assignee
- Kürzere Zeiträume: z. B. letzte 30 Tage
- Pro Projekt abfragen statt alle Projekte
- Paginierung: z. B. 50–100 Ergebnisse pro Anfrage
Lösungen und Best Practices
1. Paginierung einsetzen
Paginierungs-Muster
Große Abfragen in kleine Seiten aufteilen:
// Aufgaben in Batches von 50
page = 1
all_tasks = []
while True:
batch = list_tasks(limit=50, page=page)
if batch is empty:
break
all_tasks.extend(batch)
page += 12. Filter konsequent nutzen
Filter-Beispiele
// Statt:
list_tasks() // Liefert alle Aufgaben
// Mit Filtern:
list_tasks(
status="in_progress",
project_id=123,
assigned_to="[email protected]",
created_after="2026-01-01"
)3. Lese-Operationen bündeln
Batching-Strategie
Bei Details für viele Aufgaben: Anfragen bündeln:
- Task-IDs mit list_tasks holen (leichtgewichtig)
- get_task-Aufrufe in Gruppen von 10–20 bündeln
- Kurze Pause zwischen Batches (100–200 ms)
Details im Batching-Guide.
4. Client-Timeout erhöhen
Längere Timeouts konfigurieren
Manche Clients erlauben Timeout-Einstellung:
- Cursor: Einstellungen auf Timeout-Override prüfen
- Continue: In config.json konfigurieren
- Eigene Clients: Timeout z. B. 90–120 Sekunden
Hinweis: Längerer Timeout ist ein Workaround. Besser: Abfragen optimieren.
Debug-Checkliste
- Ergebnismenge prüfen: Wie viele Ergebnisse werden geladen?
- Filter setzen: Mit Status, Projekt oder Datum eingrenzbar?
- Paginierung testen: 50 Ergebnisse ok, 500 schlagen fehl?
- Netz prüfen: Speed-Test und Ping zu api.corcava.com
- Einfache Abfrage: Funktioniert get_task (eine Aufgabe)?
- Rate-Limits: Treten 429-Fehler auf?
