Skip to main content
Glama
cygnussystems

cygnus-ssh-mcp

Official

ssh_dir_remove

Remove a remote directory via SSH immediately; no dry-run, and set recursive to true to delete non-empty directories.

Instructions

Remove a directory on the remote system - this is the simple rmdir/Remove-Item equivalent. There is NO dry-run/preview mode here (unlike ssh_dir_delete below) - it acts immediately. If recursive=False (default) and the directory is not empty, this RAISES an exception rather than returning an error dict - it does not partially delete anything.

For a safer recursive delete with a preview step, use ssh_dir_delete instead, which defaults to dry_run=True and returns a graceful {'status': 'error', ...} on failure instead of raising.

Returns: {'status': 'success', 'path', 'recursive', 'message', 'connection'} on success. Raises an exception on failure (non-empty directory with recursive=False, path not found, permission denied, etc.) rather than returning an error dict.

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
pathYesDirectory path to remove
use_sudoNoUse sudo for the operation
recursiveNoRemove directory and contents recursively

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: immediate action, exception rather than error dict on non-empty dir with recursive=False, no partial deletion, and the in_progress/handle_id polling contract with the single-operation 'busy' constraint. The only gap is that it does not discuss sudo/permission requirements beyond noting permission-denied as a failure cause.

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 core action and the sibling comparison, then structured into failure behavior and long-running behavior. The 'Returns:' block partially restates what the output schema already encodes, adding some redundancy, but the exception and handle_id details are not recoverable from structured fields.

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?

Covers purpose, alternative routing, failure mode, partial-delete semantics, and the async polling contract for a tool that can exceed the server wait cap. Nothing an agent needs to invoke it correctly is missing.

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 baseline is 3, but the description goes beyond the schema by spelling out the behavioral consequence of recursive=False (raises rather than partially deleting) and confirming the default. use_sudo is left to the schema alone, so it falls 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 and resource ('Remove a directory on the remote system') and immediately anchors it to the familiar rmdir/Remove-Item semantics, which lets an agent distinguish it from ssh_dir_delete without opening either 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?

Explicitly routes the agent: use this for simple non-preview removal, use ssh_dir_delete for a safer recursive delete with a dry_run preview step. It also warns there is NO dry-run here, so the when-not is stated, not inferred.

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