Syncthing MCP

syncthing_devices

Destructive

List, inspect, add, patch, or remove Syncthing device configurations and view pending device requests, with write actions requiring confirm=true.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "syncthing_devices"
  }
}

Input Schema

Name	Required	Description
`id`	No	Folder id or device id for get, patch, and remove.
`action`	Yes	Syncthing operation to call.
`confirm`	No	Boolean true runs the write when SYNCTHING_ALLOW_WRITES is true. Omit it or pass false for a dry-run preview that sends nothing. The string true is rejected.
`document`	No	JSON object for add, patch, and patch_options. Official collection PUT routes that expect arrays are excluded; POST add takes one object.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds genuinely new context: writes require both confirm=true and an environment-level SYNCTHING_ALLOW_WRITES=true flag, and non-confirmed calls are silent dry runs. This is valuable behavioral disclosure the annotations cannot convey. It does not describe what remove actually destroys (e.g., whether folder shares referencing the device are affected), leaving one gap.

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?

Three short sentences, front-loaded with the resource and action list, then the document rule, then the write gate. The phrasing is telegraphic ('Device config list, get, add, patch, remove, and pending requests') but nothing is wasted. Slight redundancy between the action list and the trailing 'Actions:' enumeration.

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?

With four parameters, a fully described schema, and no output schema, the description covers the essentials: which actions are writes, the double gate for executing them, and the dry-run default. It leaves the semantics of 'pending' and the irreversibility/scope of remove unstated, which a destructive tool could reasonably spell out.

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 coverage is 100%, so the schema already documents action, id, confirm, and document in detail. The description only restates that add and patch take a JSON object and that confirm gates writes, adding little beyond the structured fields. Baseline 3 applies when the schema carries the parameter burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (Syncthing device config / pending device requests) and enumerates the exact operations: list, get, add, patch, remove, pending. This is enough to separate it from sibling tools like syncthing_folders or syncthing_config without opening a schema. It stops short of an explicit statement of how it differs from those siblings, so it falls just under a 5.

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?

It gives concrete operating conditions: writes only occur when confirm is true AND SYNCTHING_ALLOW_WRITES=true, and omitting/false confirm yields a dry-run that sends nothing. That is actionable when-to-use guidance for the mutation actions. It does not explicitly say when to prefer this tool over syncthing_folders or syncthing_config, so no exclusions are stated.

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

Deploy Server