Skip to main content
Glama
Negm-Ahmed

Desktop Commander

by Negm-Ahmed

write_file

Write or append file contents in 25-30 line chunks to create and update files within allowed directories, using absolute paths for reliable operation.

Instructions

                    Write or append to file contents. 

                    CHUNKING IS STANDARD PRACTICE: Always write files in chunks of 25-30 lines maximum.
                    This is the normal, recommended way to write files - not an emergency measure.

                    STANDARD PROCESS FOR ANY FILE:
                    1. FIRST → write_file(filePath, firstChunk, {mode: 'rewrite'})  [≤30 lines]
                    2. THEN → write_file(filePath, secondChunk, {mode: 'append'})   [≤30 lines]
                    3. CONTINUE → write_file(filePath, nextChunk, {mode: 'append'}) [≤30 lines]

                    ALWAYS CHUNK PROACTIVELY - don't wait for performance warnings!

                    WHEN TO CHUNK (always be proactive):
                    1. Any file expected to be longer than 25-30 lines
                    2. When writing multiple files in sequence
                    3. When creating documentation, code files, or configuration files
                    
                    HANDLING CONTINUATION ("Continue" prompts):
                    If user asks to "Continue" after an incomplete operation:
                    1. Read the file to see what was successfully written
                    2. Continue writing ONLY the remaining content using {mode: 'append'}
                    3. Keep chunks to 25-30 lines each
                    
                    Files over 50 lines will generate performance notes but are still written successfully.
                    Only works within allowed directories.
                    
                    IMPORTANT: Always use absolute paths for reliability. Paths are automatically normalized regardless of slash direction. Relative paths may fail as they depend on the current working directory. Tilde paths (~/...) might not work in all contexts. Unless the user explicitly asks for relative paths, use absolute paths.
                    This command can be referenced as "DC: ..." or "use Desktop Commander to ..." in your instructions.

Input Schema

NameRequiredDescriptionDefault
modeNorewrite
pathYes
contentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.3

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It explains performance characteristics (files over 50 lines generate performance notes), constraints (only works within allowed directories), path handling (absolute vs. relative paths), continuation behavior for incomplete operations, and chunking requirements. This provides rich behavioral context beyond basic functionality.

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?

While the description is well-structured with clear sections and bullet points, it is quite lengthy with multiple repetitions about chunking and path handling. Some information (like the 'DC: ...' reference) seems less essential. The description could be more concise while retaining its comprehensive guidance.

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

Completeness5/5

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

Given the tool's complexity (file writing with performance considerations), lack of annotations, and no output schema, the description provides complete contextual information. It covers purpose, usage patterns, behavioral constraints, parameter semantics, error handling, and performance considerations. Nothing essential appears to be missing for effective tool use.

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

Parameters5/5

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

With 0% schema description coverage for 3 parameters, the description must and does compensate by providing extensive parameter semantics. It explains the 'mode' parameter values ('rewrite' vs 'append') with concrete usage examples, clarifies 'path' parameter requirements (absolute paths for reliability), and implicitly describes 'content' parameter usage through chunking guidelines. This adds significant meaning beyond the bare schema.

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?

The description explicitly states the tool's purpose as 'Write or append to file contents', which is a specific verb+resource combination. It clearly distinguishes this from sibling tools like read_file, edit_block, and move_file by focusing on writing/creating file content rather than reading, editing specific blocks, or moving files.

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

Usage Guidelines5/5

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

The description provides extensive guidance on when and how to use this tool, including explicit instructions for chunking ('Always write files in chunks of 25-30 lines maximum'), a step-by-step process for writing files, and specific scenarios when chunking should be used. It also contrasts with implied alternatives by emphasizing this is the 'normal, recommended way' rather than emergency measures.

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