Optional install of HTTP/SSE transport deps (express, hono) for stdio-only servers

Summary

The TypeScript SDK currently lists express@^5.2.1, hono@^4.11.4, @hono/node-server, cors, express-rate-limit, etc. as direct dependencies (not optional, not peer). For a server that only uses the stdio transport (the most
common deployment for local MCP servers), none of those frameworks are loaded at runtime — but they are still installed in node_modules and walked by every supply-chain analyzer (Socket, Snyk, Scorecard, etc.).

Why this matters

I just published mercury-invoicing-mcp@0.2.0, a stdio-only MCP server. The published tarball is a single 33 KB bundled dist/index.js — but Socket flagged 6 alerts that all originate from the express dependency tree:

• parseurl@1.3.3 — typo-squat AI suggestion (gptDidYouMean: parseuri)
• content-disposition@1.1.0 — "unstable property" warning
• network access, env vars, fs, URL strings — all legitimate but each generates an alert chain

For maintainers of stdio-only servers, none of this is actionable: we can't fix an Express transitive dep we don't import.

Suggestion

1. Sub-package split — sdk-core + sdk-http + sdk-stdio
2. Optional peer deps — express/hono as peerDependencies with peerDependenciesMeta.optional: true (lightest-touch)
3. Conditional exports — same dep tree, but importable submodules so bundlers can tree-shake

Option 2 is the smallest change with the biggest supply-chain win.

Repro

npm init -y
npm install @modelcontextprotocol/sdk
npm ls --all | grep -E "express|hono|parseurl|content-disposition" | wc -l
# 60+ transitive deps that an stdio-only server never touches

Happy to PR option 2 if there's interest.

Start by reviewing the SDK package manifest and the current transport dependency declarations. Compare the optional peer-dependency approach with the existing stdio and HTTP/SSE usage, then verify that stdio-only installs avoid the HTTP dependency tree while HTTP/SSE servers can still install and use those packages.