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.

[sandstream]

Another stdio-only consumer, with a measurement rather than a +1 — because the install count is the weaker half of this argument, and it's the half that's easy to wave away ("it's just disk").

The question that actually decides whether an advisory is actionable is which of those packages execute. So I traced it on kit (stdio-only, StdioServerTransport, four direct production deps: @modelcontextprotocol/sdk, @upstash/redis, smol-toml, zod), at SDK 1.30.0:

	count
production packages in the tree	94
reachable only through the SDK	90
reachable without the SDK	4
actually loaded at runtime	9

Loaded set, in full: @modelcontextprotocol/sdk, zod, zod-to-json-schema, smol-toml, ajv, ajv-formats, fast-uri, fast-deep-equal, json-schema-traverse.

All twelve of express, express-rate-limit, cors, hono, @hono/node-server, raw-body, content-type, eventsource, eventsource-parser, jose, pkce-challenge, ip-address are installed and none of them is loaded — at server construction, through listTools(), and through real tool calls.

Method, because a half-blind tracer gives a confident wrong answer

An ESM resolve hook alone reports 5–6 packages and misses fast-uri: ajv is CommonJS, so its internal require("fast-uri") is invisible to module-resolution hooks. The trace needs both halves — a register()ed resolve hook and a Module._load patch — before absence proves anything. My first attempt at this measurement had exactly that bug and under-reported.

Why this is worth more than the disk footprint

It's the triage cost, and it lands on consumers who cannot fix any of it. In one sitting this repo cleared four dependency advisories; three came from the SDK subtree, and they were not the same kind of finding:

• hono — installed, never loaded. Unreachable from our code.
• ip-address (via express-rate-limit) — installed, never loaded. Unreachable.
• fast-uri (via ajv) — genuinely on the live path. ajv compiles our tool schemas on every server start and resolves $ref URIs through it.

The dependency graph cannot tell those apart; only the trace can. So the SDK's hard-dependency set does not just add noise — it makes the reachable advisories harder to find, because they arrive mixed in with unreachable ones from the same parent. That is the cost I'd emphasise over node_modules size.

Worth saying plainly: the SDK's tree is not all dead weight for us (ajv/zod are load-bearing). The ask isn't "fewer dependencies" — it's that the HTTP/OAuth transport set specifically is separable, and today it isn't.

On the options

Option 2 (peerDependencies + peerDependenciesMeta.optional) or a @modelcontextprotocol/sdk-http companion would both work for us; option 2 needs no import-path changes on our side, so it's the one I'd take.

Happy to contribute the trace harness if it's useful for validating such a split — it's a regression test in our repo (src/mcp-dependency-surface.test.ts), so if a future SDK release pulls the HTTP stack onto the stdio path, we find out from a failing test rather than from a scanner.

Reproducing the counts above needs nothing from kit: a lockfile reachability walk from the four direct deps, and the two-hook trace while booting any stdio server.