Skip to main content
Glama
Sign In
SSH MCP Server

SSH MCP Server

by YawLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ssh_find

Read-only

Search files on a remote host over SSH with structured parameters, avoiding manual find syntax. Filter results by name, type, size, depth, or modification time.

Instructions

Search for files on a remote host. Wraps the find command with structured parameters so you don't have to construct find syntax manually.

Input Schema

NameRequiredDescriptionDefault
hostYesSSH hostname or IP address
nameNoFilename pattern with wildcards (e.g. '*.log', 'config.*')
pathYesDirectory to search in (e.g. /var/log, /home/user)
portNoSSH port (default: 22)
typeNoFile type: f=file, d=directory, l=symlink
newerNoReference file path -- find matches files modified more recently than this file
maxsizeNoMaximum file size (e.g. '10M', '500k')
minsizeNoMinimum file size (e.g. '1M', '100k')
timeoutNoCommand timeout in milliseconds (default: 30000). Also the longest the call waits for a free connection-pool slot (SSH_MCP_MAX_POOL_SIZE, default 100) before the command starts; the wait and the command are bounded separately.
maxdepthNoMaximum directory depth to search (0 = the path itself only)
passwordNoSSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process.
usernameNoSSH username (default: current user)
privateKeyPathNoPath to SSH private key

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.18.1
    • changedInput schema / properties / maxdepth / description
      Previous value: -"Maximum directory depth to search"New value: +"Maximum directory depth to search (0 = the path itself only)"
    • addedInput schema / properties / maxdepth / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / maxdepth / minimum
      Added value: +0
    • changedInput schema / properties / maxdepth / type
      Previous value: -"number"New value: +"integer"
  2. Changed1 schema field changedv0.17.0
    • changedInput schema / properties / timeout / description
      Previous value: -"Command timeout in milliseconds (default: 30000)"New value: +"Command timeout in milliseconds (default: 30000). Also the longest the call waits for a free connection-pool slot (SSH_MCP_MAX_POOL_SIZE, default 100) before the command starts; the wait and the command are bounded separately."
  3. Changed1 schema field changedv0.11.0
    • addedInput schema / properties / newer
      Added value: +{
+  "description": "Reference file path -- find matches files modified more recently than this file",
+  "type": "string"
+}
  4. Addedv0.9.1

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and network profile is known. The description adds that the operation runs remotely via a wrapped find, but says nothing about result shape, permission failures, partial output, or how the timeout/pool behavior (documented only in the schema) affects the call.

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?

Two front-loaded sentences with no filler; the purpose arrives first and the rationale second. It is efficient, though it leaves the description thin relative to a 13-parameter tool.

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?

With full schema coverage and read-only annotations, the description is minimally sufficient to invoke the tool correctly. However, for a search tool with no output schema, it omits the return format (matched paths? metadata?) and gives no guidance relative to the many sibling listing/inspection tools.

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

Parameters3/5

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

Schema description coverage is 100%, so every one of the 13 parameters is already documented in structured data, including wildcard syntax, size units, and the timeout/pool note. The description adds no parameter-level meaning beyond that, which is the expected baseline.

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?

States a specific verb and resource ('Search for files on a remote host') plus the underlying mechanism ('wraps the find command'), which separates it from siblings like ssh_ls or ssh_stat. It never names a sibling explicitly, so the differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'so you don't have to construct find syntax manually' implies when this tool is preferable to raw ssh_exec, but there are no explicit when-to-use/when-not rules, no mention of ssh_ls as the lighter alternative for simple listing, and no prerequisites or exclusions.

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