diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md
index 5acb28b..3a22dec 100644
--- a/docs/teilprojekte.md
+++ b/docs/teilprojekte.md
@@ -573,7 +573,17 @@ und Letzteres verlangt die **physische Bestätigung am Gerät** — ap1 Technik
   | `docker-compose.yml` | `https://n8n.emsenhuber.net` (hartkodiert, ignoriert die `.env`) | `web` | `${HOST_PORT:-3000}` |
   | **laufender Container** | `http://n8n:5678` ← korrekt, Container-DNS | `n8n_default` | `3001` |
 
-  Zu tun: Netz als `external: true` auf `n8n_default`, `N8N_API_URL` aus der Env statt hartkodiert,
+  🔴 **Vorsicht — die naheliegende Lösung ist die falsche.** Ein `tools/call n8n_health_check` (statt
+  nur `initialize`) zeigt: **n8n-mcp hat einen SSRF-Schutz und lehnt private Adressen ab** —
+  `"SSRF protection: Private IP addresses not allowed", apiUrl: http://n8n:5678`. Die
+  Container-DNS-Adresse des laufenden Containers **funktioniert also gar nicht**; sie im Compose
+  festzuschreiben würde den Zustand zementieren, nicht heilen. Umgekehrt war
+  `https://n8n.emsenhuber.net` im Compose vermutlich **Absicht**, kein Drift — nur eben über den
+  CF-Umweg, was der TP16.3-Stossrichtung zuwiderläuft. Ein Abschalter für den Schutz ist im Image
+  nicht ersichtlich (nur `TRUST_PROXY`). **F4 muss diesen Zielkonflikt lösen**, nicht nur Dateien angleichen.
+  ⚠️ **Aktueller Ausfallumfang:** die **Doku-Tools laufen** (`search_nodes` ✅ — das ist die
+  Hauptfunktion von `n8n-documentation-mcp`), nur die **n8n-Instanz-Management-Tools** (`n8n_*`) sind tot.
+  Zu tun: Netz als `external: true` auf `n8n_default`, `N8N_API_URL` **erst nach Klärung des SSRF-Punkts**,
   Image auf den laufenden Digest pinnen (`sha256:2c8ff077…` = v2.57.1; heute `:latest` +
   `pull_policy: always`, was bei jedem Recreate unkontrolliert hochzieht), Bind auf `10.40.20.167`.
   ⚠️ **`N8N_API_KEY` ist in allen drei Quellen verschieden**; der laufende und der aus