Good callout, and you’re right on the spec. The loopback callback currently uses a fixed port (8787), so if another local process is already sitting on that port (Cloudflare wrangler dev defaults to 8787, and Dask and a few others can land there too), the connect fails - Cursor either can’t stand up the callback listener or the redirect hits the wrong server.
Quick workaround: free up 8787 while you run the MCP Connect flow (stop the other service, or start it on a different port). The listener only needs the port during the auth handshake, so once you’re connected the token is saved and you can put the other service back on 8787.
On the larger point: moving to an OS-assigned ephemeral port instead of a fixed 8787 is a reasonable change. Since it’s a separate issue from the redirect-URI change this thread started on, would you mind opening a new thread in Bug Reports so it can be tracked on its own? A few details would help: whether you’re hitting this in the IDE or the CLI, which tool was holding 8787, and what the failure looked like (an error, a hang, or nothing happening).