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

[klodr]

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.

[jibbius]

+1 from another stdio-only consumer. I’m trying to bring this into my workplace, and I’m expecting the size of the dependency tree (92 packages / ~22 MB, with @modelcontextprotocol/sdk as the only direct dep) will raise concerns — likely a blocker. Option 2 would be a great solution.