Skip to main content
Glama
Sign In

Remote Desktop Commander

by app.desktopcommander
OverviewDiscussionsAdmin

write_file

Destructive
                    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.

                    Paths refer to the selected device. Relative paths depend on that device's 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

NameRequiredDescriptionDefault
modeNorewrite
pathYes
contentYes
deviceIdNoThe ID of the device to run this tool on (from list_devices). Required when more than one device is online; may be omitted when only one device is connected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description adds substantial context on top: chunk sizes of 25-30 lines, performance notes above 50 lines, a sandbox restriction to allowed directories, and path-resolution caveats for relative and tilde paths. It stops short of stating outright that mode='rewrite' truncates existing file contents, which is the single most important consequence for a destructive tool.

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

Conciseness4/5

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

Well front-loaded and organized under CHUNKED WRITES and FORMAT HANDLING headers, so an agent can scan it. Slight redundancy remains: the 50-line performance note and the 25-30 line chunk advice overlap, and the 'DC: ...' invocation line is boilerplate that doesn't help 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 destructive, four-parameter write tool with no output schema, the definition covers formats, modes, chunking, sandbox limits, and path resolution. It leaves open whether parent directories are auto-created and what error surface a failed or permission-denied write produces.

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?

Schema coverage is only 25% (deviceId alone is documented), so the description carries the burden and does: it defines the rewrite-vs-append semantics of mode, explains that content type is determined by extension with a concrete Excel JSON 2D-array example, and gives guidance on absolute vs relative vs tilde paths. That is meaning well 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?

Opens with a specific verb+resource ('Write or append to file contents') and immediately routes PDF and DOCX-editing cases to their dedicated siblings. An agent can tell this apart from write_pdf and edit_block 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 Guidelines5/5

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

Explicitly names the alternatives and the conditions selecting them: PDF creation goes to write_pdf, existing DOCX content goes to edit_block, new DOCX files are created here. It also prescribes the rewrite-then-append pattern for long content, which is real when-to-use guidance rather than restatement.

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

All Remote Desktop Commander toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources