modelcontextprotocol/sdk brings in a whole node http server

[mlh758]

Command

update

Description

I've had something like 7 Hono related dependabot PRs since January related to the MCP SDK. Looking at #32293 it is expected that the MCP should only be running in stdio mode. Why then does this bring in a dependency on hono and hono/node-server?

I don't mind the MCP suddenly being included, but it would be nice if it hadn't expanded the dependency footprint this dramatically. This has turned into something of a compliance liability for me.

Describe the solution you'd like

The MCP dependency either no longer requires hono, or the MCP features for Angular CLI become a peer dependency or a separate package that is optional to pull in.

Describe alternatives you've considered

We use Angular quite a bit, and like it, so there isn't really a great alternative.

[alan-agius4]

The hono package is a dependency of @modelcontextprotocol/sdk. While it could potentially be classified as an optional peer dependency, this change must be implemented within the MCP TypeScript SDK rather than our codebase.

Furthermore, we cannot move @modelcontextprotocol/sdk to a peer dependency because the Angular CLI is often installed globally, which would lead to resolution issues.

Although we could technically isolate these features into a separate NPM package to avoid this dependency, we are not considering that architectural change at this time.

[mlh758]

These MCP tools look largely like things already covered by the CLI and are marked experimental. Do you feel these were worth expanding the footprint of the CLI rather than publishing a separate MCP server for the CLI? Is there a good place to provide feedback about this? I can't be the only person whose compliance tools are complaining about a node server suddenly being installed as part of a build tool.

[alan-agius4]

To be honest, this is the first time we’ve received this specific feedback.

Our general strategy is to minimize the number of NPM packages we publish for several reasons. Regarding the concern about compliance tools flagging a Node server within a build tool: it is actually standard practice. Many of the core build tools we rely on such as Vite, Vitest, esbuild, Webpack, and Karma include a dev-server component as part of their functional design.

Technically, any Node.js package has the inherent capability to spin up a server, even if it doesn't list a specific transitive dependency for one.

We'd like to understand the compliance trigger better, can you please share the report?

[mlh758]

It's Vanta, the issue is more that I keep getting dinged for CVEs in Hono. I have an easier time justifying dismissing alerts on a dev server that is clearly never meant for production. Hono is, and presumably the MCP SDK includes it in order to function as an HTTP based MCP server. I've been able to update Hono each time but it's inevitable that eventually some incompatibility is going to hang us up and I'll be stuck having to justify putting off a patch until we can update some other conflicting package.

This isn't a huge deal for me, I should be clear. The CLI is a dev dependency and this isn't going to get me in any real trouble. It's just a lot of extra footprint I wouldn't have opted into if I'd had a choice and it's caused some minor toil having to keep pulling another patch for Hono.

[mlh758]

Put another way I don't think it's odd to be concerned that the footprint of the build CLI for Angular has suddenly expanded and become a regular source of CVEs I have to deal with. Angular has been delightfully low noise for me up until now.