When the client will not connect
Each refusal, what it actually means, and the gesture it asks for — including the version negotiation that only a real client could find.
Shipped in the current build. You can do this on your own machine today.
Most of what looks like a failure here is a refusal, and a refusal names its gesture. The table separates the two.
| What you see | What it means | What to do |
|---|---|---|
| Server’s protocol version is not supported | The client and the server did not agree on a revision of the protocol. MCP is negotiated: the client announces its version, and the server answers with that one if it speaks it. | Update Deskworth. Since 0.0.24 the server speaks four revisions and reflects the client’s own when it knows it. |
| Deskworth is not running — open the app, then try again | The server started, and the application is closed. The server is a thin front; the work happens in the app. | Open Deskworth, then ask the client to reconnect. |
| The declaration exists and nothing is connected | Declaring a server does not connect to it. The status comes from a real handshake. | Check the binary path in the declaration — the client launches it, so a moved application breaks it. |
| Connected, and no tools | The handshake succeeded and the surface did not. | Check that the binary is from a 0.0.24 build or later; the external surface does not exist before it. |
| A tool answers with an error instead of failing | That is a tool refusing with a reason, not a broken server — the protocol separates the two on purpose. | Read the reason. It is written to be acted on. |
#The negotiation, and why no test found it
The first real client refused to connect. The server announced the newest revision it knew and required it; the client asked for an older one and stopped there. Nothing in the suite could have caught it: the server was consistent with itself, and it is the client that decides.
The correction is what the protocol always said: a version is negotiated, not imposed. The server now speaks four revisions, offers the most recent by default, and answers with the client’s own when it recognises it. This is the difference between “covered by tests” and “exercised by a real client” — and it is why this site keeps those two words apart everywhere else.
EvidenceIf your client reports a version mismatch, the useful information is the version it asked for. That is the one the server has to speak, and adding a revision to the list is a smaller change than it sounds.
#Reading the process yourself
- The server is a normal subprocess: your client launched it, and it stops when its input closes.
- Only protocol messages go to standard output. Anything the server has to say for itself goes to standard error, where your client usually shows it.
- A single unreadable line does not take the session down — it is answered and the loop continues.
#Sources
- Deskworth OS — product state at 0.0.24, providers and MCPDeskworthInternal document, not published
- The external MCP surface, mirrored on this siteDeskworthInternal document, not published
- Model Context Protocol — stdio transportModel Context Protocol projecthttps://modelcontextprotocol.io/specification/2026-07-28/basic/transports/stdio
- Connect Claude Code to tools via MCPAnthropichttps://code.claude.com/docs/en/mcp