diff --git a/kong/mcp/pluginbindings.yaml b/kong/mcp/pluginbindings.yaml
index 0fa96a4..9177773 100644
--- a/kong/mcp/pluginbindings.yaml
+++ b/kong/mcp/pluginbindings.yaml
@@ -34,6 +34,37 @@ spec:
       kind: KongRoute
       name: ${NAME}-customers-mcp
 ---
+# Also bind to the GET/-stream route, not just the POST/DELETE one above.
+# Without this, GET requests never reach ai-mcp-proxy at all and fall
+# through to the KongService's own upstream target — which is
+# ${REST_HOSTNAME} (Kong's own external hostname, mcp/service.yaml), so an
+# unintercepted GET loops back into the Gateway and grows response headers
+# on every pass until nginx rejects it ("upstream sent too big header",
+# 502) — confirmed 2026-08-23 via customers dataplane pod logs (28
+# occurrences) while debugging a LibreChat connection failure specific to
+# customers-mcp. catalog-mcp has the identical gap (checked: its
+# ai-mcp-proxy-binding also targets only the non-stream route) but happens
+# to fail as a harmless 405 there instead of looping — not fixed here,
+# flagged in STATUS.md, don't assume catalog's GET stream actually works
+# just because nothing broke loudly.
+apiVersion: configuration.konghq.com/v1alpha1
+kind: KongPluginBinding
+metadata:
+  name: ${NAME}-customers-mcp-ai-mcp-proxy-stream-binding
+  namespace: ${NAMESPACE}
+spec:
+  controlPlaneRef:
+    type: konnectNamespacedRef
+    konnectNamespacedRef:
+      name: ${CONTROL_PLANE_REF_NAME}
+  pluginRef:
+    name: ${NAME}-customers-mcp-ai-mcp-proxy
+  targets:
+    routeRef:
+      group: configuration.konghq.com
+      kind: KongRoute
+      name: ${NAME}-customers-mcp-stream
+---
 apiVersion: configuration.konghq.com/v1alpha1
 kind: KongPluginBinding
 metadata: