Synology DSM

Setup

1. In DSM create a user for the integration. Give it read access to the shared folders the agent should see and, if you want the system tools, membership of the administrators group — several SYNO.Core endpoints are admin-only.
2. Turn off two-factor authentication for that user, or the login call cannot complete. This is the main reason to use a dedicated account rather than your own.
3. Set SYNOLOGY_URL to your NAS (e.g. https://nas.example.com:5001, no trailing slash), plus SYNOLOGY_USERNAME and SYNOLOGY_PASSWORD.

DSM's session is a sid. The adapter logs in at /webapi/auth.cgi, passing the account and password as query parameters (which is what DSM's auth CGI expects), and passes the returned sid back as the id cookie on every call. It logs in again once the cached session is an hour old. DSM reports an expired session as error 119 inside an HTTP 200, which the automatic retry-on-401 does not catch: if a call answers 119, run it again after the session has been renewed. AnythingMCP keeps the session encrypted in connector_auth_cache.

The password reaches DSM in a URL, because that is the only thing auth.cgi accepts — so it lands in the NAS's own access log. This is another reason to give the integration its own account rather than reusing yours, and to rotate it like any other credential.

Every call names an API, a version and a method. DSM's Web API is one CGI endpoint per family with api, version and method as query parameters — entry.cgi?api=SYNO.Core.System&version=1&method=info. That is why the tools here look repetitive in the trace; the parameters are what distinguish them.

Success is in the body, not the status code. DSM answers {"success": false, "error": {"code": 105}} with HTTP 200. Code 105 is 'insufficient permission', 119 'session expired', 400 'no such account or wrong password'. A 200 is not a result.

Valid TLS is required, and a fresh DSM does not have it. Synology ships a self-signed certificate; this connector will refuse it. DSM has built-in Let's Encrypt support under Control Panel → Security → Certificate — use it.

File Station paths start at the shared folder, e.g. /documents/invoices, not /volume1/documents/invoices; a volume path answers error 408 (no such file or folder). synology_list_shares gives the share names.

Search is two calls. synology_search_files only starts a search and returns a taskid; synology_get_search_results reads the matches for that task (call it again until finished is true).

Read-only by design: no file writes, no share changes, no package management.

Self-hosted, which is the thing to plan for.

• On AnythingMCP Cloud the instance must be reachable from the public internet on a real hostname with a valid TLS certificate. A self-signed certificate will fail: the connector offers no trust-anything switch, and a homelab's default certificate is exactly the case that breaks.
• On an internal host (nas.intern, 10.0.0.x), self-host AnythingMCP on the same network and add that host to SSRF_ALLOWED_HOSTS, or the outbound guard refuses the call before it is made.