Bug im MCP

# Bug: POST /mcp bricht die Verbindung ab, statt 401 zurückzugeben

Server: https://mcp.parqet.com — parqet-mcp, Version 0.0.1

Datum der Prüfung: 2026-09-14

Auswirkung: Kein MCP-Client kann sich verbinden. Der OAuth-Flow wird nie erreicht.

## Zusammenfassung

GET /mcp antwortet korrekt mit 401. POST /mcp dagegen bricht die TCP-Verbindung

ohne Antwort ab — unabhängig von Headern, Protokollversion und davon, ob ein

Authorization-Header gesendet wird.

Das verhindert jede Nutzung des Servers: Der MCP-Handshake ist per Spezifikation

immer ein POST mit der initialize-Methode. Da der Server dabei die Verbindung

zurücksetzt, erhält der Client nie den 401 mit dem WWW-Authenticate-Header, der

den OAuth-Flow gegen https://connect.parqet.com auslösen würde. Clients melden

lediglich ECONNRESET.

## Reproduktion

\# 1) Funktioniert — Server antwortet korrekt mit 401

curl -i https://mcp.parqet.com/mcp -H "Accept: text/event-stream"

\# 2) Bricht ab — erwartet wäre 401

curl -i -X POST https://mcp.parqet.com/mcp \

  -H "Content-Type: application/json" \

  -H "Accept: application/json, text/event-stream" \

  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'

Erwartet (2): HTTP 401 mit WWW-Authenticate-Header

Tatsächlich (2):

• HTTP/2: curl: (92) HTTP/2 stream 1 was closed cleanly, but before getting all response header fields
• HTTP/1.1 (--http1.1): curl: (52) Empty reply from server
• Node fetch: TypeError: fetch failed / cause: other side closed

## Testmatrix

| Anfrage | Ergebnis |

|---|---|

| GET / | 200 (Discovery-JSON) |

| GET /health | 200 |

| GET /.well-known/oauth-protected-resource | 200 |

| GET /mcp | 401 — korrekt |

| POST /mcp, ohne Authorization | Verbindung zurückgesetzt |

| POST /mcp, mit Authorization: Bearer \<dummy> | Verbindung zurückgesetzt |

| POST /mcp, nur Accept: application/json | Verbindung zurückgesetzt |

| POST /mcp, erzwungen HTTP/1.1 | Empty reply from server |

## Ausgeschlossene Fehlerquellen

Client- und netzwerkseitige Ursachen wurden per Gegenprobe ausgeschlossen:

• POST https://httpbin.org/post → 200 (POST funktioniert generell)

• POST https://mcp.notion.com/mcp mit identischem Payload → 401

  (POST gegen einen fremden MCP-Server funktioniert und liefert sauber 401)

Beide Gegenproben liefen von derselben Maschine, im selben Netzwerk, mit demselben

Client. Der Fehler tritt ausschließlich bei POST gegen mcp.parqet.com/mcp auf.

## Vermutete Ursache

Der POST-Handler bzw. die Auth-Middleware wirft vermutlich eine unbehandelte

Exception, bevor eine Antwort geschrieben wird, sodass der Prozess bzw. der Worker

die Verbindung schließt. Ein GET läuft durch einen anderen Codepfad, der den

401 korrekt zurückgibt.

## Erwartetes Verhalten

POST /mcp ohne oder mit ungültigem Token sollte — wie GET /mcp bereits — mit

401 und einem WWW-Authenticate-Header antworten, damit MCP-Clients den

OAuth-Flow starten können.