mrkeyoor.com_
Tue 01 Sept 16:17 UTC
Code ExecutionMCP servermeasured 19 Aug 2026

Desktop Commander

Desktop Commander is a community MCP server from wonderwhy-er that hands a model your actual machine: read and write files, apply surgical edits, run shell commands, and drive long-lived processes over stdio. We started version 0.2.47 and it advertised 26 tools plus 2 resources and no prompts.

BootBOOTS ✓We started it and initialize came back in 55.1s.
Tools26tools/list payload 60,997 bytes
Context tax~15,226estimated tokens for the whole tools/list, chars/4 estimate
Resources / prompts2 / 0counts returned by resources/list and prompts/list
Measured19 Aug 2026one run of the harness, clean environment, no credentials · how we test

How we started it

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

Use it if you genuinely want an agent with a shell and a filesystem, and you accept both prices. The first is context: its tools/list came back at 60,997 bytes, roughly 15,226 tokens by the chars/4 estimate, which is a large standing cost before the model has done anything. The second is blast radius, since start_process and write_file are exactly as dangerous as they sound. Everything else about it works.

Use it if

You want one server that covers file edits and shell processes instead of bolting a filesystem server to a terminal server
Your agent needs to start a long-running command, read its output later, and kill it, which the process tools handle as sessions rather than one-shot calls
You are working in a VM, container, or throwaway machine where an agent writing files is an acceptable outcome
You run a long-context model and can absorb a five-figure token estimate on every request

Skip it if

You only need to read files, in which case a filesystem-only server costs a fraction of the context
The machine holds credentials, customer data, or anything you would not hand a stranger with a keyboard
You are on a small context window and need room for the actual conversation
Your client charges per input token and you make many short calls, since the tools/list rides along each time
You want narrow, auditable permissions; this server's surface is broad by design and config is set through its own set_config_value tool

The bill for your context window

ToolEst. tokensDescribed?Required params
start_search~1,841yes (6393 chars)2
start_process~1,410yes (5053 chars)2
read_file~1,309yes (4381 chars)1
edit_block~1,144yes (3701 chars)1
interact_with_process~1,092yes (3826 chars)2
write_pdf~1,047yes (3079 chars)2
write_file~865yes (2718 chars)2
list_directory~724yes (2274 chars)1

This is one of the heavier servers we measured, and unusually the weight is not in the number of tools but in how much each one explains itself. 26 tools, about 15,226 estimated tokens. start_search alone carries roughly 1,841 of them, start_process 1,410, and read_file 1,309, so three tools account for a visible share of the bill while force_terminate gets by on 139. Those long descriptions are not padding; they are the author teaching the model to chunk reads and treat processes as sessions, and the behavior improvement is real. You are still paying for that tutorial on every single request. If your client supports per-tool filtering, cut the PDF writer, the feedback tool, and the usage stats and you will keep the capability at a lower standing cost.

Setup reality

There is no auth dance and nothing to sign up for. Our clean-env probe scraped no environment variable names at all, so npx -y @wonderwhy-er/desktop-commander over stdio is the whole configuration. The catch is the first run: cold, with npm fetching the package tree, initialize took 55,104 ms, and npm printed a wall of deprecation warnings for old glob, rimraf, and uuid transitives on the way. Later runs come off the npx cache and are nothing like that. Configuration lives in the server's own config file, reachable through get_config and set_config_value, including the allowed-directories setting you should set before pointing this at anything real.

Questions people ask

Why did Desktop Commander take so long to start?

That was a cold npx install, not the server. Our probe ran with an empty cache, so initialize measured 55,104 ms while npm pulled the dependency tree. Once the package is cached locally, startup is ordinary. Budget the wait for the first launch on a new machine or in CI.

Is Desktop Commander safe to run?

It is as safe as the machine you run it on. It executes shell commands and writes files with your user's permissions, and our harness deliberately ran it as an unprivileged probe user. Set the allowed-directories config before real use, and never run it as root on a box that matters.

Do I still need a separate filesystem MCP server?

No. Its file tools cover reading, writing, moving, directory listing, and block-level edits, so running both duplicates capability and doubles the context cost. Pick one. If you want only reads and no shell, the smaller filesystem server is the cheaper choice.

How many tools does Desktop Commander expose?

When we booted it on 2026-08-19 it listed 26 tools, 2 resources, and no prompts, speaking protocol 2025-06-18. The set spans files, search, process control, and its own configuration. Tool count is stable across versions, but description lengths drift, so the token estimate moves with releases.

Other code execution servers we started

ServerVendorBootsContext tax
E2B Code SandboxE2B~72 tokens

How this page is made: the server is spawned as an unprivileged user with a clean environment and no credentials, then asked for its tools, resources and prompts over stdio. Token figures are estimates at four characters per token, not a tokenizer count. One run, one machine. Corrections: contact the desk.

← All measured MCP servers