Skip to main content
Glama

Remote Desktop Commander

read_process_output

Read-only
                    Read output from a running process with file-like pagination support.
                    
                    Supports partial output reading with offset and length parameters (like read_file):
                    - 'offset' (start line, default: 0)
                      * offset=0: Read NEW output since last read (default, like old behavior)
                      * Positive: Read from absolute line position
                      * Negative: Read last N lines from end (tail behavior)
                    - 'length' (max lines to read, default: configurable via 'fileReadLineLimit' setting)
                    
                    Examples:
                    - offset: 0, length: 100     → First 100 NEW lines since last read
                    - offset: 0                  → All new lines (respects config limit)
                    - offset: 500, length: 50    → Lines 500-549 (absolute position)
                    - offset: -20                → Last 20 lines (tail)
                    - offset: -50, length: 10    → Start 50 from end, read 10 lines
                    
                    OUTPUT PROTECTION:
                    - Uses same fileReadLineLimit as read_file (default: 1000 lines)
                    - Returns status like: [Reading 100 lines from line 0 (total: 5000 lines, 4900 remaining)]
                    - Prevents context overflow from verbose processes
                    
                    SMART FEATURES:
                    - For offset=0, waits up to timeout_ms for new output to arrive
                    - Detects REPL prompts and process completion
                    - Shows process state (waiting for input, finished, etc.)
                    
                    DETECTION STATES:
                    Process waiting for input (ready for interact_with_process)
                    Process finished execution
                    Timeout reached (may still be running)

                    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 new output. If nothing new arrives, call again later. Larger timeout_ms values are accepted but capped at 3000ms.

Input Schema

NameRequiredDescriptionDefault
pidYes
lengthNo
offsetNo
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.5/5.0
Behavior5/5

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

Annotations declare readOnly/non-destructive, and the description adds substantial non-obvious context on top: output truncation via fileReadLineLimit, the literal status line format returned, blocking behavior for offset=0 up to timeout_ms, and the 3000ms cap under remote execution. This is exactly the operational detail annotations cannot convey.

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?

Front-loaded with the verb and the pagination model, then layered detail, which is the right ordering. The examples block is somewhat padded (offset: 0 with and without length restates the same behavior) and the 'DC: ...' branding line plus the REMOTE EXECUTION section add length, though the latter carries real behavioral 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?

For a 6-parameter, 1-required tool with no output schema, the description supplies the return shape (status line), the blocking/timeout model, and per-offset behavior — enough to call it correctly. The main residual gap is verbose_timing, whose effect on the response is left entirely to the schema's type-only declaration.

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 description coverage is only 17%, so the description must carry the load, and it does for the two parameters that matter most: offset (with three distinct sign-based semantics and worked examples) and length (default plus config source). timeout_ms gets partial treatment, but verbose_timing and the semantics of pid are never explained, leaving a small gap.

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 opening sentence states a specific verb and resource ('Read output from a running process') plus the distinguishing capability ('file-like pagination support'). It is clearly separable from siblings like list_processes, start_process, and interact_with_process, which do not read accumulated output.

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 offset semantics section effectively documents the different usage modes (poll-new, absolute position, tail), which functions as when-to-use guidance per parameter value. The DETECTION STATES block routes the agent to interact_with_process when the process is waiting for input. It stops short of explicitly stating when not to use this tool (e.g., after force_terminate or on a finished pid).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.