DesktopCommanderMCP tool descriptions consume 15k–20k context tokens — any fix?
DesktopCommanderMCP ships 21 tools whose descriptions consume roughly 15,000–20,000 tokens of Claude's context before any conversation starts — up to 30–40% of a 190k-token budget. The longest descriptions are start_search (83 lines), start_process (61 lines), and interact_with_process (58 lines). Is there a fix or workaround to reduce this overhead without breaking how well Claude actually uses the tools?
Originally asked on GitHub: https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/266
4 answers
Status: still open. The maintainer confirmed the token bloat is a real problem but rejected the specific fix proposed in the report. The verbose descriptions were built iteratively from cases where Claude misused the tools, so naive trimming risks degrading tool selection. The maintainer's planned direction is to remove less-used tools and combine methods into single tools, which was already done for code/file search. No release or implementation is shown in this thread.
A commenter suggested a hybrid “pseudocode + structure” format as a middle ground: keep a compact signature block like
start_process(command, timeout_ms, shell?, verbose_timing?), a one-line purpose, and only the key constraints, cutting an example description from ~500 tokens to ~150. This was discussed but not implemented.The report's original proposal — replace descriptions with 1–2 sentence summaries and load full docs on demand via
get_tool_docs(tool_name)— was rejected by the maintainer, who said it would not work because the long text exists precisely to make Claude use the tools correctly. Commenters also noted that lower token count alone is not proof of quality and suggested building regression tests from the maintainer's collected failure cases to compare before/after tool-use effectiveness.General advice: if context limits hurt your workflow today, consider loading fewer MCP servers or enabling DesktopCommanderMCP only during terminal/file-heavy work. Watch the repository for the planned tool consolidation.
Did this work for you?What a GitHub user tried on GitHub (Outcome unclear)
Reporter proposed replacing verbose descriptions with 1–2 sentence AI-optimized summaries and exposing full docs on demand via get_tool_docs(tool_name). The maintainer rejected the idea, saying the long descriptions were built from real failure cases where Claude misused the tools, but the proposal itself was never tried.
Source: https://github.com/wonderwhy-er/DesktopCommanderMCP/issues/266 (opens external site)
Did this work for you?What @Jaesun23 tried on GitHub (Outcome unclear)
Commenter proposed a hybrid pseudocode + structure format, showing a start_process example reduced from ~500 tokens to ~150 tokens while keeping the function signature and key constraints. Discussed as an idea; not implemented in the thread.
Did this work for you?What @Jaesun23 tried on GitHub (Outcome unclear)
Commenter suggested building regression tests from the maintainer's collected failure cases to compare tool-use quality before and after any description change. Proposed only; no results shown.
Did this work for you?
Related questions
- Is there a way to rollback changes made by DesktopCommanderMCP?
- DesktopCommanderMCP: 'MCP error -32001: Request timed out' on startup with Claude Desktop
- DesktopCommanderMCP fails to attach under nvm: require() of ES modules is not supported
- search_code errors in DesktopCommanderMCP on Claude Desktop, then falls back to read_file/search_files
- DesktopCommanderMCP polls running processes in a loop and hits Claude limits — how to make it wait?