Skip to main content
Glama
Sign In

Remote Desktop Commander

by app.desktopcommander
OverviewDiscussionsAdmin

start_process

Destructive
                    Start a terminal process on the authorized device with intelligent state detection.
                    
                    Suitable for shell commands, interactive REPL sessions, data-processing scripts,
                    programmatic file analysis, and other long-running terminal work.
                    
                    The connected device determines shell syntax and available commands. Windows devices commonly use PowerShell or CMD; macOS and Linux devices commonly use Unix shells. Use commands and paths appropriate for the selected device.
                    
                    Examples:
                    • start_process("python3 -i") → Start an interactive Python REPL
                    • start_process("node -i") → Start an interactive Node.js REPL
                    • start_process("node:local") → Run stateless Node.js code on the MCP server
                    • start_process("wc -l /path/file.csv") → Run a one-shot shell command

                    Interactive process sessions support follow-up input after they are started.
                    Long-running process sessions expose newly available output while they remain active.
                    Binary files can be processed with appropriate command-line tools or libraries available
                    in the selected process environment.

                    SMART DETECTION:
                    - Detects REPL prompts (>>>, >, $, etc.)
                    - Identifies when a process is waiting for input
                    - Recognizes process completion vs timeout
                    - Early exit prevents unnecessary waiting
                    
                    STATES DETECTED:
                    Process waiting for input (shows prompt)
                    Process finished execution
                    Process running (use read_process_output)

                    PERFORMANCE DEBUGGING (verbose_timing parameter):
                    Set verbose_timing: true to get detailed timing information including:
                    - Exit reason (early_exit_quick_pattern, early_exit_periodic_check, process_exit, timeout)
                    - Total duration and time to first output
                    - Complete timeline of all output events with timestamps
                    - Which detection mechanism triggered early exit

                    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.

REMOTE EXECUTION: Remote execution waits at most 3 seconds for completion or a prompt. If the process is still running, it continues in the background and returns its PID. Larger timeout_ms values are accepted but capped at 3000ms.

Input Schema

NameRequiredDescriptionDefault
shellNo
commandYes
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.
timeout_msNo
verbose_timingNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only mark it as non-readOnly, destructive and open-world; the description adds substantially to that: the 3000ms remote-execution cap despite higher timeout_ms values, background continuation with PID return, early-exit heuristics, and the three detectable states. Those are exactly the behavioral traits an agent cannot infer from the structured fields.

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?

Purpose is correctly front-loaded and the device/syntax caveat is well placed, but the body is bloated: 'SMART DETECTION' and 'STATES DETECTED' restate the same idea, and the 'DC: ...' invocation-aliasing note adds little for tool selection. Roughly a third of the text could be cut without losing decision-relevant information.

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?

With no output schema, the description does the heavy lifting: it explains what comes back when the process keeps running (background PID), how to read new output, and how to debug timing. It falls just short of complete because the 'shell' parameter and the normal (non-background) return payload are never characterized.

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

Parameters4/5

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

Schema coverage is only 20% (only deviceId documented), so the description must compensate and largely does: it explains command syntax via examples, that the connected device determines shell/path semantics, the real timeout ceiling, and verbose_timing's full output contents. The 'shell' parameter, however, is never mentioned anywhere, leaving one of five parameters completely undefined.

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 and resource (start a terminal process on the authorized device) and enumerates concrete instantiations (Python REPL, Node REPL, one-shot shell command). It also names what this tool is not for: when the process is running, it says to use read_process_output, letting an agent separate it from that sibling without opening a 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?

The 'Suitable for...' sentence plus four worked examples give a clear picture of when to reach for it, and the description points to read_process_output for the running-state case. It stops short of explicitly contrasting with interact_with_process (it only hints that sessions 'support follow-up input' after start), so the boundary between starting and interacting is left partly implicit.

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