Connecting to a server is something you can already do; keeping a local checkout and a remote one honest during a session is the thing that normally means a second tool and a second config. The design decision to look at is that automatic sync deploys an FTP service on the remote box rather than using rsync over the existing SSH connection — that is a port and a service you are responsible for, and the disable tool exists precisely because you should turn it off when the session ends.
A remote development helper: it manages server definitions — direct SSH, a relay jump host, or a Docker container — connects to them, runs commands, and handles the two-way code synchronisation that usually needs a separate tool.
- Server management: `list_servers` for what is configured, `get_server_status` for connection state, `connect_server` and `execute_command` for actually working on one
- `git_sync` reconciles a local repository with its remote counterpart — you name the server, both paths and a branch, with optional commit hash and a force mode; local changes are stashed rather than lost
- `autosync_enable` deploys an FTP service on the remote host and configures local synchronisation, so edits propagate while you work; `autosync_disable` stops the service and cleans up
- Sync configuration covers the FTP port, user and password, and include and exclude patterns — by default Python, JavaScript and Markdown files are carried and compiled artefacts, caches and version-control internals are not
- A guided configuration wizard covers SSH details, container settings and sync options
The npm package @xuyehua/remote-terminal-mcp, run through npx from the client configuration. Servers are configured through the wizard or the configuration file. The sync tools have preconditions worth knowing before you start: the local path must exist and must be a git repository, and the remote host must permit the FTP service to start.
One command — npm install @xuyehua/remote-terminal-mcp