Skip to main content
Glama
Negm-Ahmed

Desktop Commander

by Negm-Ahmed
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

read_process_output

Read output from a running process and detect REPL prompts or completion automatically, preventing timeouts and hangs while showing whether it waits for input or has finished.

Instructions

                    Read output from a running process with intelligent completion detection.
                    
                    Automatically detects when process is ready for more input instead of timing out.
                    
                    SMART FEATURES:
                    - Early exit when REPL shows prompt (>>>, >, etc.)
                    - Detects process completion vs still running
                    - Prevents hanging on interactive prompts
                    - Clear status messages about process state
                    
                    REPL USAGE:
                    - Stops immediately when REPL prompt detected
                    - Shows clear status: waiting for input vs finished
                    - Shorter timeouts needed due to smart detection
                    - Works with Python, Node.js, R, Julia, 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.

Input Schema

NameRequiredDescriptionDefault
pidYes
timeout_msNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.3

TDQS

B3.4/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by detailing behavioral traits: early exit on REPL prompts, detection of completion vs running states, prevention of hanging, and clear status messages. It explains what the tool does beyond basic reading, though it could mention error handling or output format.

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

Conciseness2/5

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

The description is overly verbose and poorly structured, with redundant sections (e.g., 'SMART FEATURES' and 'REPL USAGE' overlap), bullet points that could be condensed, and unnecessary marketing language ('This command can be referenced as...'). It lacks front-loading of critical information.

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

Completeness3/5

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

Given no annotations, no output schema, and low schema coverage, the description is moderately complete. It covers behavioral aspects well but misses parameter details and return value explanation. For a tool with smart detection features, it's adequate but has gaps in technical specifics.

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

Parameters2/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 for the two parameters (pid, timeout_ms). It mentions 'timeout' briefly but doesn't explain what pid represents, the units for timeout_ms, or default behaviors. The description adds minimal semantic value beyond the bare schema.

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

Purpose4/5

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

The description clearly states the tool reads output from a running process with intelligent completion detection, which is a specific verb+resource combination. It distinguishes from siblings like 'interact_with_process' by focusing on reading output rather than sending input, though the distinction could be more explicit.

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 description provides clear context for when to use this tool: when a process is running and output needs to be read with smart detection. It implies an alternative ('interact_with_process' for when the process is waiting for input) but doesn't explicitly name it or provide exclusion criteria.

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