Syncthing MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | HTTP port. | 3000 |
| MCP_TRANSPORT | No | stdio or http. The --http option overrides this. | |
| SYNCTHING_URL | No | Required. Origin only, http or https, with no userinfo, query, hash, or path. Example: http://127.0.0.1:8385. | |
| SYNCTHING_API_KEY | No | Required unless SYNCTHING_API_KEY_FILE is set. Sent as X-API-Key and redacted in logs, errors, and tool results. | |
| SYNCTHING_CONTACT | No | Contact token in the User-Agent. Must not contain the API key. | |
| SYNCTHING_PER_MINUTE | No | Local request budget. Cache hits do not spend it. | 30 |
| SYNCTHING_TIMEOUT_MS | No | Upstream timeout in milliseconds. | 20000 |
| SYNCTHING_ALLOW_WRITES | No | Must be the literal true before a confirmed write is sent. | |
| SYNCTHING_API_KEY_FILE | No | Optional. chmod 600 file whose trimmed contents are the API key. Used when SYNCTHING_API_KEY is omitted. | |
| SYNCTHING_CACHE_TTL_SEC | No | Read cache TTL in seconds. Writes clear the cache. | 60 |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| syncthing_systemA | System health, ping, status, version, connections, discovery, errors, pause, resume, restart, and shutdown. Writes run only when confirm is true and SYNCTHING_ALLOW_WRITES=true. Omit confirm or pass false for a preview that sends nothing. Actions: health, ping, status, version, connections, discovery, errors, error_clear, pause, resume, restart, shutdown. |
| syncthing_configA | Read the full config (GUI secrets redacted), restart-required flag, and options. patch_options merges a JSON object into options. Writes run only when confirm is true and SYNCTHING_ALLOW_WRITES=true. Actions: get, restart_required, options, patch_options. |
| syncthing_foldersA | Folder config list, get, add, patch, remove, and pending offers. add and patch take a JSON document object. Writes run only when confirm is true and SYNCTHING_ALLOW_WRITES=true. Actions: list, get, add, patch, remove, pending. |
| syncthing_devicesA | Device config list, get, add, patch, remove, and pending requests. add and patch take a JSON document object. Writes run only when confirm is true and SYNCTHING_ALLOW_WRITES=true. Actions: list, get, add, patch, remove, pending. |
| syncthing_dbA | Folder status, need, file metadata, errors, completion, scan, and folder/device statistics. scan is a write. Writes run only when confirm is true and SYNCTHING_ALLOW_WRITES=true. Actions: status, need, file, errors, completion, scan, folder_stats, device_stats. |
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 5 tools
The five tools are cleanly partitioned by resource domain (system, config, folders, devices, db), so an agent can usually pick the right one from the noun alone. There is some residual overlap: syncthing_system exposes status/errors while syncthing_db exposes folder status/errors/completion, and syncthing_folders.get vs syncthing_db.folder_stats could be confused without reading the action lists.
All tools share the syncthing_ prefix plus a single domain noun, which is predictable and readable. The names are noun-only rather than verb_noun, and syncthing_db breaks the 'config resource' pattern slightly, so the verb is hidden inside the action parameter.
Five tools for a Syncthing admin surface is well-scoped: each domain (system, config, folders, devices, db) earns its place and nothing looks redundant. The heavy action multiplexing is handled inside each tool rather than by inflating the tool count.
Coverage is strong: read/write lifecycle for folders and devices, config read/patch, pending offers/requests, and runtime status, need, completion, and scan. Minor gaps exist for event/log streaming and version upgrade operations, but agents can work around them.