shipback-sftp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_sitesA | List the configured sites: name, host, remote root and default local folder. No passwords. |
| preview_deployA | Show what a deploy would upload (new and changed files). Changes nothing. Returns a planId that deploy needs. |
| deployA | Upload the previewed plan. Every file it overwrites is backed up on the server first, and the whole deploy can be undone with restore. Never deletes server files. Refuses if the plan changed since preview_deploy. |
| check_server_changesA | Before editing a site's local files: list files that are different or only on the server (someone edited the live site). Changes nothing. |
| pullA | Download the server-side changes into the local folder, so local is the truth before editing. Local files it overwrites are backed up in /_backup-/. Never deletes local files. |
| list_backupsB | List the backups on the server, newest first, with what each run overwrote, added and deleted. |
| preview_restoreA | Show what restoring a backup would put back and remove, and any conflicts (live files edited after that run). Changes nothing. Returns a planId that restore needs. |
| restoreA | Undo a deploy: put the backed-up files back and remove the files that run added. Backs up the current live files first, so the restore can itself be restored. Refuses on conflicts unless force is true; only pass force when the user has seen the conflicts and said to go ahead. |
| historyC | Recent deploys, pulls and restores from this machine. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Tools are clearly delineated: preview/deploy and preview/restore form explicit two-step pairs, while check_server_changes vs pull are complementary but distinct. No overlapping purposes or ambiguous boundaries.
Mostly action-oriented and consistent with list_*, preview_*, check_*, and bare verbs like deploy, pull, restore. 'history' is the lone noun, and mixing bare verbs with verb_noun is a minor deviation.
9 tools is well within the ideal range. Each maps to a distinct step in the deploy/pull/restore workflow with no filler or redundancy.
Core lifecycle is covered: list sites, preview/deploy, preview/restore, pull, check changes, and list backups. Gaps include no management of local backups created by pull and no add/edit/remove site operations (only list_sites).