Skip to main content
Glama
lunix1024

Rex SSH MCP

by lunix1024

ssh_write_file

Destructive

Write UTF-8 text files over SFTP on a remote Linux host, using atomic replacement and optional backup to protect existing content.

Instructions

Write UTF-8 text through SFTP on the selected server using a temporary file and atomic rename. Existing files are backed up by default. Replacing symlinks is refused. SSH credentials are private server-side configuration. Never ask the user for a password. Use ssh_list_servers when the user has not supplied an exact configured alias.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
serverYesExact configured server alias returned by ssh_list_servers.
contentYes
createBackupNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already mark destructiveHint=true, but the description adds behavioral details: backups by default, refusal to replace symlinks, and credential handling (private server-side config, never ask password). These go beyond annotations, so the agent understands safety and edge cases.

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

Conciseness5/5

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

Five sentences with no filler, each adding distinct information. The main action is first, followed by safety and usage notes. Efficient and well-organized.

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

Completeness4/5

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

For a 4-parameter tool with no output schema, the description covers the core behavior, backup, symlink handling, and credential rules, plus routing to ssh_list_servers. It could mention return value or error behavior, but given the tool's simplicity, it's fairly complete.

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 only 25%, with server having a description. The description adds context that content is UTF-8 text and mentions backup default and symlink refusal, which inform path and createBackup semantics. However, it doesn't explicitly define path requirements or content format beyond UTF-8, so it partially compensates but not fully.

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?

The description clearly states the action: writing UTF-8 text via SFTP to a selected server, with specifics like atomic rename and backup. It distinguishes from siblings like ssh_upload_file (likely binary) and ssh_exec (commands) by focusing on text content and SFTP write semantics.

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 explicitly instructs to use ssh_list_servers when the user hasn't provided an exact alias, and warns never to ask for a password. It does not explicitly exclude other file operations, but the alias condition and password rule give clear context for when to use this tool.

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