@modelcontextprotocol/express 2.0.2: Bearer Auth Targeting and Server Instancing Changes
Version 2.0.2 introduces resource-specific bearer token validation and enforces single-use server/transports per connection or request. This release affects authentication flows and backend code structure for all users upgrading from 2.0.1.
What changed?
In @modelcontextprotocol/express 2.0.2, the middleware functions requireBearerAuth and verifyBearerToken now accept a new optional parameter: expectedResource. When provided, these helpers will only accept bearer tokens issued for the specified resource (checked as the token's audience). This enables more precise API authentication for resource-specific authorization scenarios.
Additionally, a significant behavioral change was introduced: a Server (or McpServer) now serves one connection at a time, and a Streamable HTTP server transport without sessions only serves one request. If you reuse a server or a 'stateless' transport for more than one request, subsequent requests will fail. Apps must now construct a fresh server and transport instance per request or session.
Why does it matter to an everyday developer?
The new expectedResource option increases security by preventing tokens issued for a different audience (resource) from being accepted on your endpoints. This matters for developers building backends where endpoints should only authorize tokens minted specifically for them, improving robustness against misuse of tokens.
The server-per-request change is a breaking behavioral update. If your code previously reused a single server or stateless transport instance (e.g., as a singleton), your app will now fail on the second request, typically with an ALREADY_CONNECTED error or a rejected promise. This affects both Express and other supported frameworks.
