nuxt-mcp-dev

Hi Anthony — big fan of the Vite/Nuxt ecosystem work, nuxt-mcp-dev is a smart, narrow tool (helping models actually understand a Vite/Nuxt app instead of guessing) and exactly the kind of MCP server that should be easy to find. I'm building Lulu Ads (getlulu.dev), an opt-in ad layer for MCP servers — when an agent calls one of your tools, it can occasionally surface a disclosed, relevant sponsored suggestion next to the real result. No changes to the server itself, purely opt-in, and every suggestion is labeled as sponsored to the model so it's never passed off as your output. Given you maintain a lot of high-traffic OSS already, I know unpaid maintenance time is scarce — this is meant as a low-effort way to get something back from the MCP specifically, not a big ask. No worries if it's not useful to you. Listing page if you want to look: https://getlulu.dev/mcps/nuxt-mcp-dev

Describe the bug MCP Server fails to start in VScode Chat pane customizations MCP servers whenever I try to start: Output shows this: Note that it works when added manually following the documentation instructions. Issue only occurs when I try to add it automatically (screenshot below shows vscode automatically added mcp server not running, while the other one added with is working) Reproduction Open VScode chat pane (secondary pane) > Gear icon (Open Customizations) > MCP Servers > Browse Marketplace > Add Nuxt. System Info Used Package Manager npm Validations [x] Follow our Code of Conduct [x] Read the Contributing Guide. [x] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate. [x] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead. [x] The provided reproduction is a minimal reproducible of the bug. Contributions [ ] I am willing to submit a PR to fix this issue [ ] I am willing to submit a PR with failing tests (actually just go ahead and do it, thanks!)

Only one MCP client can use the dev server at a time today, and the rest silently get a broken connection. connects every incoming SSE transport to a single shared . The SDK's owns exactly one transport per instance and throws on the second , so every client after the first fails. That rejection is also uncaught, so it escapes as an instead of failing just the one request. In practice this is easy to hit: an editor and one or more CLI agents attached to the same dev server. Whichever connects first wins and the others get nothing useful. Changes takes a factory and creates one per SSE connection, so clients are independent. The session map now holds each transport with its server, and that server is closed when its response closes. A failed connect is answered as a 500 on that request rather than escaping as an unhandled rejection. A caller-supplied option may still hand back a shared instance. That stays working: the newest client takes over rather than throwing. Creating a server per connection is cheap, since only registers tool closures. Tests covers concurrent clients each getting their own instance, a disconnect dropping only that client, the shared-instance takeover, and a failing connect returning 500 instead of rejecting. Three of the four fail on .