[laboef1900]

Summary

Bumps @modelcontextprotocol/sdk to the first patched release for GHSA-6qxp-vccf-f47h ("OAuth client could send credentials to an authorization server chosen by the MCP server") in both lockfiles that carry it, keeping backend and sidecar on the same version.

Package	Lockfile	From	To	Alert
@modelcontextprotocol/sdk	package-lock.json (root; backend mcp-docs-client)	1.30.0	1.31.0	#279 (high)
@modelcontextprotocol/sdk	mcp-docs/package-lock.json	1.30.0	1.31.0	#276 (high)

No other package changes: the diff is the version/resolved/integrity lines of the SDK entry in each lockfile (6 lines per file), plus the CHANGELOG entry. 1.31.0 declares the same dependencies, peer dependencies and engines as 1.30.0, and npm install in both locations left the lockfiles unchanged after the bump. The ^1.30.0 ranges in backend/package.json and mcp-docs/package.json already allow 1.31.0, so neither package.json changes and no overrides are needed. I pinned 1.31.0, the patched version, rather than letting npm update pull 1.32.1. 1.32.0 changes how the HTTP client handles redirects (it now follows only same-origin redirects), which is outside this fix.

Compatibility notes

I read the release notes for 1.30.1 and 1.31.0 and ran npm diff on the published packages.

• 1.31.0: binds stored OAuth tokens and client info to their issuer (new issuer field; expectedIssuer on ClientCredentialsProvider/PrivateKeyJwtProvider). Neither the backend nor mcp-docs uses the SDK's OAuth support. The backend client authenticates with the x-mcp-docs-token header via requestInit, not with an authProvider. client/streamableHttp.js and client/index.js are unchanged between the two versions.
• 1.30.1: the Streamable HTTP server transport now limits the request bodies it reads itself to 4 MiB, and rejects JSON-RPC batches of more than 100 messages. mcp-docs runs express.json() (100 kB default) and passes req.body as parsedBody, so the body limit doesn't apply to it. The batch limit does apply, and the backend only sends single messages. createMcpExpressApp now registers the JSON parser after Host validation, but we don't use it.
• APIs in use, unchanged: McpServer, server.tool, StreamableHTTPServerTransport, isInitializeRequest (sidecar), Client, StreamableHTTPClientTransport (backend).

Verification

• mcp-docs: npm run typecheck clean; npm test → Test Files 10 passed (10), Tests 79 passed (79); npm run build clean.
• backend mcp-docs-client.test.ts + mcp-docs-settings.test.ts: Test Files 2 passed (2), Tests 7 passed (7).
• backend npm run typecheck and npm run lint clean.
• Full backend suite (--maxWorkers=4): Test Files 445 passed (445), Tests 7143 passed | 3 skipped (7146).
• Smoke test: I started the built sidecar (node dist/index.js, PORT 3199, Redis, MCP_DOCS_TOKEN set) and connected to it with the backend's real mcp-docs-client (SDK 1.31.0, only the settings lookup mocked), using a throwaway script that I've since deleted:
  • testConnection() → {"ok":true,"tools":["fetch_url","search_web","list_cached"]}
  • fetchDocumentation('http://127.0.0.1:6379/') → rejected SSRF blocked: private IP address
  • fetchDocumentation('https://example.com/') → title "Example Domain", content returned
  • wrong token → {"ok":false,...,"error":"Streamable HTTP error: Error POSTing to endpoint: {\"error\":\"Unauthorized\"}"}