Skip to main content
Glama
cygnussystems

cygnus-ssh-mcp

Official

ssh_dir_search_glob

Recursively find remote files or directories matching a filename glob pattern over SSH, so you can locate paths by name without searching file contents.

Instructions

Recursively search for files (or directories, with include_dirs=True) matching a filename glob pattern (e.g. *.log) - matches by NAME only, not content; use ssh_dir_search_files_content instead to search inside files. For metadata beyond just path/type (size, mtime, permissions), use ssh_dir_list_advanced instead.

max_depth uses standard find -maxdepth semantics: this is the same on both Linux/macOS and Windows despite the different underlying commands. max_depth=1 means the given path itself plus its immediate children only (not grandchildren); omit max_depth for unlimited recursion.

On a 'linux'/'flex' connection with a limited BusyBox-style find (no -printf - check ssh_conn_connect/ssh_conn_host_info's capabilities), this raises a clear error instead of running. Fallback: ssh_dir_list_files_basic (non-recursive filenames, match the pattern yourself) - SFTP-based and unaffected by this, at the cost of one call per directory level.

Returns: List of {'path': str, 'type': str} - type is a single-character code (f=file, d=directory, l=symlink) from the underlying find/stat output, not a spelled-out word.

Long-running calls: if this takes longer than the server's wait cap (default 50s), it
returns {"status": "in_progress", "handle_id": ...} instead of the result - the work keeps
running. Get the result by polling ssh_cmd_check_status(handle_id=...), which returns this
tool's normal response once finished. Do not call it again meanwhile. Only one such
operation runs at a time; another one started meanwhile fails with a 'busy' error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesBase directory to search from
patternYesFilename glob pattern (e.g. *.log)
use_sudoNoUse sudo for the operation
max_depthNoMaximum recursion depth (None for unlimited)
include_dirsNoInclude matching directories in results

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.6.1
    • addedOutput schema / properties / result / anyOf
      Added value: +[
      +  {
      +    "items": {},
      +    "type": "array"
      +  },
      +  {
      +    "additionalProperties": true,
      +    "type": "object"
      +  }
      +]
    • removedOutput schema / properties / result / items
      Removed value: -{}
    • removedOutput schema / properties / result / type
      Removed value: -"array"
  2. First observedv1.3.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so well: it discloses the cross-platform max_depth behavior, the BusyBox find failure mode (errors instead of running), the return shape with single-character type codes, and the long-running in_progress/handle_id polling protocol including the one-at-a-time busy constraint.

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?

Purpose is front-loaded, then alternatives, then semantics, limitations, and returns in clearly ordered blocks. It is on the long side and the long-running paragraph is dense, but nearly every sentence delivers operative detail rather than filler.

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?

With an output schema present the description needn't restate return values, yet it adds the non-obvious type-code decoding. Combined with the BusyBox limitation, fallback path, and async polling contract, an agent has everything needed to call and recover from this tool.

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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains find -maxdepth semantics and that max_depth=1 includes the base path plus immediate children only, and it documents when include_dirs applies. use_sudo is left to the schema, keeping it short of a 5.

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 (recursively search), resource (files/directories), and scope (filename glob, name-only) in the first sentence. It explicitly differentiates itself from two siblings by name, so an agent can route correctly 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?

Names the alternatives and the exact condition that selects them: ssh_dir_search_files_content for content matching, ssh_dir_list_advanced for metadata, and ssh_dir_list_files_basic as a fallback when BusyBox find lacks -printf. When-to-use and when-not-to-use are both covered.

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