All articles

An MCP server that timed out on every start

2 min readNotes

nitrateX Building with agents

One of my coding agent's MCP servers kept failing to connect with a timeout. The fix was to stop downloading it at every start.

The symptom

The agent client starts each MCP server as a child process and waits a limited time for it to answer. One server, a desktop and terminal toolkit, failed almost every time with CONNECT_TIMEOUT. Run by hand, it started without errors.

The cause

Its plugin config launched it like this:

npx -y @wonderwhy-er/desktop-commander@latest

With @latest, npx checks the registry and may download and unpack the package before anything runs. On a slow network or a cold cache that easily takes longer than the client is willing to wait. The server was healthy; it just wasn't ready in time.

The fix

Install a pinned version once, into a prefix I can write to without sudo:

npm install -g --prefix ~/.local @wonderwhy-er/desktop-commander@0.2.52

Then point the server entry at the installed binary instead of npx:

"command": "/home/me/.local/bin/desktop-commander",
"args": []

After reloading the plugins it connected on the first try, and it has started instantly since.

Things to know

  • Pinning trades freshness for speed. Updates no longer arrive by themselves; update on purpose with the same install command and a new version.
  • Plugin sync can undo it. In my setup the plugin config file can be regenerated from its source, which puts npx back. If the timeout returns, check that file first.
  • The general rule: any MCP server started with npx -y package@latest pays a download check on every launch. If a server times out only sometimes, measure its cold start before suspecting the server.

Share on X

nitrateX Building with agents

Get new articles by email

Only when a new article is out. No ads. Details →