Skip to main content
Glama
wonderwhy-er

Claude Desktop Commander MCP

by wonderwhy-er
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

write_file

Destructive

Write or append to file contents.

Instructions

                    Write or append to file contents.

                    PDF creation is handled by the dedicated write_pdf tool.
                    Existing DOCX content can be edited with edit_block. New DOCX files can be created here; markdown headings (#, ##, ###) are converted to styled DOCX paragraphs.

                    CHUNKED WRITES:
                    - Repeated calls with mode='rewrite' followed by mode='append' are supported for longer files.
                    - Chunks of roughly 25-30 lines minimize latency when writing long text, multiple files, documentation, code, or configuration files.
                    - Files over 50 lines are still written successfully but may generate performance notes.
                    - For continuation after a partial write, the existing file state can be inspected before appending the remaining content.

                    FORMAT HANDLING (by extension):
                    - Text files: String content
                    - Excel (.xlsx, .xls, .xlsm): JSON 2D array or {"SheetName": [[...]]}
                      Example: '[["Name","Age"],["Alice",30]]'

                    Only works within allowed directories.

                    Absolute paths are the most reliable because they do not depend on the current working directory. Paths are automatically normalized regardless of slash direction. Relative paths depend on the current working directory, and tilde paths (~/...) may not resolve in every context. Absolute paths are generally the most reliable.
                    This command can be referenced as "DC: ..." or "use Desktop Commander to ..." in your instructions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNorewrite
pathYes
originNo
contentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.43
    • addedInput schema / properties / origin
      Added value: +{
+  "enum": [
+    "ui",
+    "llm"
+  ],
+  "type": "string"
+}
  2. First observedv1.0.0

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=false, so the mutation/overwrite risk is covered. The description adds genuinely useful context: performance notes for files over 50 lines, the allowed-directory constraint, path normalization behavior, and per-extension format rules. It never explicitly states that mode='rewrite' destroys prior contents, which is the one behavioral gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The header-based structure is scannable and the purpose is front-loaded, but it wastes space: the absolute-path advice is stated twice in near-identical sentences, and the trailing 'DC: ...' / 'use Desktop Commander to ...' marketing line adds nothing to tool selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description covers formats, chunking strategy, path resolution, and the sandboxing constraint, which is close to what an agent needs. It leaves return-value expectations and failure behavior unstated, but annotations already carry the destructive safety profile.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate and it only partly does. It explains mode well (rewrite vs append with chunk continuation), content format for text and Excel, and path semantics (absolute vs relative vs tilde, slash normalization) — but the 'origin' enum parameter is never mentioned anywhere, leaving one of four parameters undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Write or append to file contents') and immediately routes away from siblings: PDF goes to write_pdf, existing DOCX editing goes to edit_block. An agent can distinguish this from read_file, edit_block, and write_pdf without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names alternatives with the condition that selects them (write_pdf for PDFs, edit_block for existing DOCX) and gives concrete guidance on chunked writes with mode='rewrite' followed by mode='append' and a 25-30 line chunk recommendation. It lacks any general when-not-to-use guidance (e.g. binary files, read-only directories), so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools