Summary
Consider having the SDK warn when a network-facing MCP server is started without any authentication, with an explicit opt-out. Today the SDK ships auth middleware (bearerAuth), but nothing signals when a server is exposed over HTTP with no auth at all — and that turns out to be extremely common.
Motivation (data)
I ran a full census of the official MCP Registry — every server exposing an HTTP endpoint (6,700 endpoints; 3,658 reachable). ~51% completed an unauthenticated initialize handshake (i.e. no auth at all), and independent scans (BlueRock, 2026) put OAuth adoption at ~8.5%. So this isn't an edge case — a majority of network-facing MCP servers ship with no auth, and many appear to do so unintentionally.
The SDK is the natural place to nudge the default, because it's where the server author actually stands up the transport.
Proposal
When a Streamable HTTP server transport is connected and no auth handler/middleware is detected, emit a one-time console.warn linking to the auth docs — with an explicit opt-out for intentionally-public servers, e.g.:
new StreamableHTTPServerTransport({ allowUnauthenticated: true }) // silences the warning
- Non-breaking — a warning, not enforcement.
- Opt-out keeps intentionally-public/localhost-dev servers quiet.
- Could also be scoped to non-loopback binds only (warn when listening on
0.0.0.0/public, stay silent on 127.0.0.1).
Alternatives considered
- Docs only — lowest friction, but clearly not moving the needle given the numbers.
- A startup banner /
getting-started guard.
- External linting — I built an open-source checker for this (
npx @andreolf/mcpaudit <url> grades a server A–F on auth/SSRF/injection surface), but a signal inside the SDK reaches authors far earlier.
Offer
Happy to open a PR if there's appetite — I'd start with the warning + opt-out on the Streamable HTTP server transport and wire it against the existing bearerAuth middleware detection. Wanted to check on the desired shape (warn vs. docs vs. loopback-scoped) before writing code.
Summary
Consider having the SDK warn when a network-facing MCP server is started without any authentication, with an explicit opt-out. Today the SDK ships auth middleware (
bearerAuth), but nothing signals when a server is exposed over HTTP with no auth at all — and that turns out to be extremely common.Motivation (data)
I ran a full census of the official MCP Registry — every server exposing an HTTP endpoint (6,700 endpoints; 3,658 reachable). ~51% completed an unauthenticated
initializehandshake (i.e. no auth at all), and independent scans (BlueRock, 2026) put OAuth adoption at ~8.5%. So this isn't an edge case — a majority of network-facing MCP servers ship with no auth, and many appear to do so unintentionally.The SDK is the natural place to nudge the default, because it's where the server author actually stands up the transport.
Proposal
When a Streamable HTTP server transport is connected and no auth handler/middleware is detected, emit a one-time
console.warnlinking to the auth docs — with an explicit opt-out for intentionally-public servers, e.g.:0.0.0.0/public, stay silent on127.0.0.1).Alternatives considered
getting-startedguard.npx @andreolf/mcpaudit <url>grades a server A–F on auth/SSRF/injection surface), but a signal inside the SDK reaches authors far earlier.Offer
Happy to open a PR if there's appetite — I'd start with the warning + opt-out on the Streamable HTTP server transport and wire it against the existing
bearerAuthmiddleware detection. Wanted to check on the desired shape (warn vs. docs vs. loopback-scoped) before writing code.