@pacdenis — you mentioned you’d gotten the Dorico MCP adapted to the current version. I’ve run into the same incompatibility on Dorico Pro 6.2.30: the websocket accepts the connection on 4560, then closes cleanly on the first message regardless of payload. I probed handshakeVersion 1.0, 1.1, 2.0, and no version field at all —they all gave the identical result: CLOSED: code=1000 reason=’ '. Every time. The published 0.3.0 client is speaking a protocol that isn’t there anymore.
Any chance you’d share what you built? The simplest thing on your end is probably just attaching the modified file to a reply, but Discourse blocks .py uploads, so rename it to client.py.txt and it’ll go through. Pasting the contents inside triple backticks (```) works equally well if you’d rather not deal with files.
If you’d prefer somewhere more permanent, gist.github.com takes a paste and gives you a link in about thirty seconds, no repo setup involved.
And if you’d rather keep it to yourself, no hard feelings. Even a sentence or two about what the new handshake expects would be a real gift to the next person who tries this.
I’m also a conductor/composer rather than a programmer, so I won’t pretend I’d have figured this out alone. But I’ll happily do the unglamorous half: testing on 6.2.30, documenting it, and filing the compatibility issue on the original repo so it turns up in searches.
Good evening! I’ll definitely get back to you only tomorrow and try to get access to the files. It’s just that I’m going to bed now.  It’s nice to get a message from like-minded people. I’m also a professional musician, conductor, composer, and arranger. So it’s nice to meet you. Wait, I’ll try to answer as soon as possible.
Hi! Replying with the substance, but without attaching the file — I haven’t sorted out the licensing status of the code I built on (it’s assembled on top of a third-party repo that has no explicit license), so I’m not ready to distribute it yet.
Here’s what fixed it for me on Dorico 6:
The problem: older clients wait for a kConnected response after sending connect before treating the connection as established. On Dorico 6, that response never arrives on the first-time connection — the client just hangs/drops waiting for something that isn’t coming.
What to do: stop waiting for kConnected on the first connection. Instead:
Send connect
Dorico replies with a session token (sessiontoken)
You send acceptsessiontoken back
Done — the connection is ready, you can start sending commands
You only need to wait for kConnected on a reconnect, when you already have a saved session token from a previous session and you’re reusing it.
If your 0.3.0 client is still built around “wait for kConnected right after connect,” that’s exactly where it’s breaking. Try dropping that wait for the first-time connection, and keep it only for the reconnect-with-saved-token path.