Skip to main content
Glama

Remote Desktop Commander

list_directory

Read-only
                    Get a detailed listing of all files and directories in a specified path.
                    
                    Returns a structured directory listing without starting a shell command.
                    Results distinguish between files and directories with [FILE] and [DIR] prefixes.
                    
                    Supports recursive listing with the 'depth' parameter (default: 2):
                    - depth=1: Only direct contents of the directory
                    - depth=2: Contents plus one level of subdirectories
                    - depth=3+: Multiple levels deep
                    
                    CONTEXT OVERFLOW PROTECTION:
                    - Top-level directory shows ALL items
                    - Nested directories are limited to 100 items maximum per directory
                    - When a nested directory has more than 100 items, you'll see a warning like:
                      [WARNING] node_modules: 500 items hidden (showing first 100 of 600 total)
                    - This prevents overwhelming the context with large directories like node_modules
                    
                    Results show full relative paths from the root directory being listed.
                    Example output with depth=2:
                    [DIR] src
                    [FILE] src/index.ts
                    [DIR] src/tools
                    [FILE] src/tools/filesystem.ts
                    
                    If a directory cannot be accessed, it will show [DENIED] instead.
                    If a path does not exist, it will show [NOT_FOUND] instead.
                    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
pathYes
depthNo
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
Behavior5/5

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

Beyond the readOnly/destructive annotations, it discloses the context-overflow protection rule (100-item cap on nested directories plus the warning format), the [DENIED] and [NOT_FOUND] outcomes, and the allowed-directory restriction. These are behaviors an agent could not infer from annotations or schema and would otherwise be surprised by.

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?

The core purpose and depth semantics are front-loaded and each subsequent section is a distinct, useful topic. The example output block and the trailing "DC: ..." / device boilerplate add length that could be trimmed without losing much.

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?

For a read-only listing tool with no output schema, the description fully describes the return shape ([FILE]/[DIR] prefixes, relative paths, warning lines, [DENIED]/[NOT_FOUND]). An agent has everything it needs to call the tool and interpret the response.

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 33% and the schema itself says nothing about path or depth, so the description does the heavy lifting here. It defines the depth default and what depth=1/2/3+ mean, and it explains path resolution (relative paths, tilde, absolute paths preferred), though it could clarify edge cases such as depth=0 or very large depths.

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?

It states a specific verb and resource ("Get a detailed listing of all files and directories in a specified path") and explicitly notes it returns structure without starting a shell command, separating it from start_process/interact_with_process. It is also clearly distinguishable from read_file, get_file_info, and search tools in the sibling list.

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?

It gives clear context on when the tool fits (listing a directory tree, recursive depth control) and explains what depth values select. That said, it never explicitly names an alternative such as read_file for reading contents or start_search for finding files, so routing guidance is implied rather than stated.

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.