ResponseBody not printed verbatim after receiving 401 status.

[tulshi]

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

Web

Inspector version

latest

Node version

v26.4.0

Operating system (and browser, for the web client)

No response

Transport

Streamable HTTP

MCP server under inspection

Not tested with an MCP Server on my end. I visually analyzed the code.

Steps to reproduce

1. Run MCP Inspector
2. Get your MCP Server to respond with a 401 error
3. Notice that the output does not show the responseBody.

Expected behavior

The responseBody should be printed in the logs so that one can see the OAuth Protected Resource Metadata in the WWW-Authenticate header, and the optional scope parameter.

Actual behavior

ResponseBody is not printed when the client receives a 401 status from the server.

Logs, errors, or screenshots

No response

Already prototyped a fix?

No response

Before you submit

• I searched existing issues and this is not a duplicate.
• This is not a security vulnerability report (those go through the private advisory process).

[kocaemre]

I prepared a narrow, signed branch for this issue, following the repo rule that maintainers open PRs here rather than outside contributors opening one directly.

Branch/compare:

• kocaemre:v2/fix/2297-401-response-body
• https://github.com/modelcontextprotocol/inspector/compare/v2/main...kocaemre:inspector:v2/fix/2297-401-response-body?expand=1
• commit: 8e9766fb (fix: log intercepted auth response bodies, DCO signed off)

What changed:

• keeps auth-challenge interception behavior unchanged;
• moves fetch tracking below the 401/403 auth interceptor for intercepted transport fetches, so the Monitor network log records the response status, WWW-Authenticate header, and async responseBody before AuthChallengeError is thrown;
• keeps long-lived stream body safeguards intact via the existing fetch tracker;
• adds a regression covering a Streamable HTTP 401 with WWW-Authenticate and JSON body.

Validation in this environment:

cd clients/web && npm run test -- --run src/test/core/mcp/nodeTransportFetchTracking.test.ts
# PASS: 1 file, 1 test

npm exec -- eslint core/mcp/node/transport.ts clients/web/src/test/core/mcp/nodeTransportFetchTracking.test.ts --max-warnings 0
# PASS

cd clients/web && npm run format:check -- src/test/core/mcp/nodeTransportFetchTracking.test.ts
# PASS

npm run format:check:core
# PASS

cd clients/web && npm run build
# PASS: tsc -b, vite build, tsup runner build

git diff --check upstream/v2/main..HEAD
# PASS

No PR opened from my side per the repo's maintainer-opened PR flow.

[cliffhall]

Triage: Priority Medium (total 6)

• Severity 3 — a real diagnostic surface is missing: the 401 response body (and with it the OAuth Protected Resource Metadata / scope detail) never reaches the log, so OAuth debugging is partial
• Urgency 2 — wanted, but nothing is blocked on it and the browser network panel is a workaround
• Bonuses: +1 bug label

Board: #28, Status Incoming (awaiting maintainer review — no milestone yet).

Note: a prototype branch is offered in the thread above. Per CONTRIBUTING.md a maintainer will implement this against v2/main rather than pulling the branch.