All the MCP bugs except one still seem present - .e.g. I open one copy of cursor, and it establishes, to every single non-stdio server in the list, 1+N simultaneous connections to it, where “N” is the number of entries in my mcp.json.
e.g1. I have 4 entries in my MCP right now (3 are turned off even!), and looking at just 1 of those, Cursor has redundantly opened all these connections to it at the same time, and is keeping them open:
e.g2. Cursor is still not honouring your published spec for what hooks are supposed to do (e.g. not returning the hook responses to the agent)
Can you please check and confirm that these (MCP connections and hooks, which have been reported at least a dozen times over the last 3 months!) are still present in your Engineering “to do” list for us?
@andrewh - those were just 2 examples - there a long list of other problems we have reported as well, plus new ones not reported before (TL;DR - someone in your team is getting sync and async muddled up in the MCP code, so you have massive resource mixups, memory leaks, duplication, weird side-effects and more - all of which will be found and fixed when the core underlying bug is fixed).
e.g. (new) a session I’ve had open for 24hours has 215 active simultaneous MCP connections to every server in my mcp.json - this just grows over days, until the whole thing crashes.
e.g. (reported already) the “status” reported in the IDE is not live, not true, and not real:
(I see the above in my IDE, but MCP calls do still work)
it’s some side-effect of your broken sync/async MCP code-mixup not being able to report a true answer to the UI front-end (probably because it doesn’t know which of the hundreds of accidental connections it established, is the one the rest of the code uses)
Hooks are still not working properly - can you please tap your dev team and ask them to either fix them, or, update your documentation to remove all the features that it promises, that got broken and stopped working months ago now.
