de en es ja ko ru zh

Synology Docker MCP Server

Name: Synology Docker MCP Server
Author: hifishhe

by hifishhe

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Local

Synology Docker MCP Server

(Scrollen Sie nach unten für die englische Version / English version below)

🇨🇳 中文说明 (Chinesische Version)

Dies ist ein Model Context Protocol (MCP) Server, der speziell für Synology NAS entwickelt wurde. Er dient dazu, Docker-Container und Docker-Compose-Projekte im Synology Container Manager direkt über Large Language Models zu verwalten, zu konfigurieren und zu debuggen.

✨ Kernfunktionen und Highlights

Sichere Verwaltung via SSH: Direkte Kommunikation mit Ihrem Synology NAS über SSH, sichere Ausführung nativer Befehle und vollständiger Verzicht auf das Risiko, Docker-TCP-Schnittstellen nach außen freizugeben.
Auto-Privilege Escalation (Automatische Privilegieneskalation): Automatische Injektion von Anmeldedaten zur stillen Ausführung von sudo, wodurch die bei Synology-Administratorkonten häufig auftretenden Permission Denied-Berechtigungshürden bei der Ausführung von Docker-Befehlen gelöst werden.
Perfekte Kompatibilität mit dem Synology Container Manager: Native Unterstützung und erzwungene Verwendung von docker-compose -p-Tags, um sicherzustellen, dass Projekte, die über diesen MCP-Server gestartet oder aktualisiert werden, perfekt mit der webbasierten Projektoberfläche von Synology synchronisiert bleiben (Beibehaltung des grünen Status-Punkts).
Umfassendes Toolset:
- synology_docker_ps: Alle laufenden Container anzeigen.
- synology_docker_logs: Container-Logs abrufen und verfolgen.
- synology_docker_manage: Starten, Stoppen, Neustarten oder Entfernen von Containern steuern.
- synology_project_list: Automatische Suche und Erkennung aller Projekte im Verzeichnis /volume1/docker/.
- synology_project_manage: Native Ausführung von Pull-, Up-, Down- oder Restart-Befehlen für Projekte.
- synology_read_file / synology_write_file: Remote-Lesen oder Ändern von .env- und docker-compose.yml-Konfigurationsdateien.

🔒 Sicherheitsprotokoll (v1.1.0)

Schwachstelle	Lösung
Shell-Expansion bei Sonderzeichen im Passwort (`$`/Backticks)	`echo "..."` durch `printf '%s\n' '...'` ersetzt, um Shell-Expansion zu vermeiden
Befehlsinjektion (Containername/Projektname/Pfad-Konkatenation)	Alle Benutzereingaben werden vor der Befehlskonkatenation mit `shQuote()` in einfache Anführungszeichen gesetzt
Nicht validierter `action`-Parameter	Whitelist-Validierung auf Code-Ebene, unabhängig vom Schema-Enum
Pfad-Traversal (`/etc/shadow` etc.)	`synology_read_file` / `synology_write_file` auf `NAS_DOCKER_DIR` beschränkt, Pfade mit `..` werden abgelehnt
`tail`-Parameter-Injektion	Erzwingung positiver Ganzzahlen, Obergrenze 10000, Standardwert 100
SSH-Verbindung ohne Timeout	`readyTimeout: 30000` hinzugefügt

🚀 Schnelleinstieg und Konfiguration

Synology SSH-Dienst aktivieren: Gehen Sie zu Systemsteuerung -> Terminal & SNMP und aktivieren Sie SSH-Dienst aktivieren.
Umgebungsvariablen und Anmeldedaten konfigurieren: Kopieren Sie die .env.example aus dem Projekt, benennen Sie sie in .env um und geben Sie Ihre NAS-Verbindungsinformationen ein:
```
NAS_HOST=192.168.1.xxx
NAS_PORT=22
NAS_USER=your_admin_account
NAS_PASSWORD=your_admin_password
NAS_DOCKER_DIR=/volume1/docker
```
Abhängigkeiten installieren und bauen:
```
npm install
npm run build
```

MCP-Client verbinden (z. B. Claude Desktop oder Cursor): Fügen Sie den folgenden Inhalt zur MCP-Konfigurations-JSON Ihres Clients hinzu:

{
  "mcpServers": {
    "synology-docker": {
      "command": "node",
      "args": [
        "--env-file=e:\\Dev\\Synology Docker MCP\\.env",
        "e:\\Dev\\Synology Docker MCP\\build\\index.js"
      ]
    }
  }
}

Related MCP server: QNAP Container Station MCP

🇬🇧 Englische Version

Dies ist ein Model Context Protocol (MCP) Server, der speziell für die Verwaltung, Konfiguration und das Debugging von Docker-Containern und Docker-Compose-Projekten auf Synology NAS-Geräten entwickelt wurde.

✨ Funktionen & Highlights

SSH-basierte Verwaltung: Kommuniziert direkt über SSH mit Ihrem Synology NAS und gewährleistet die sichere Ausführung nativer Befehle, ohne den Docker-TCP-Socket freigeben zu müssen.
Auto-Privilege Escalation: Injiziert automatisch Anmeldedaten, um sudo im Hintergrund auszuführen und die bei Synology-Administratorkonten üblichen Permission Denied-Probleme zu umgehen.
Kompatibilität mit dem Synology Container Manager: Native Unterstützung für docker-compose -p, wodurch sichergestellt wird, dass Projekte, die über diesen MCP-Server gestartet oder aktualisiert werden, perfekt mit der GUI des Synology Container Managers übereinstimmen (Beibehaltung der grünen Statusanzeige).
Umfassendes Toolset:
- synology_docker_ps: Alle laufenden Container anzeigen.
- synology_docker_logs: Container-Logs streamen.
- synology_docker_manage: Container starten, stoppen, neu starten oder entfernen.
- synology_project_list: Projekte entdecken, die in /volume1/docker/ gemappt sind.
- synology_project_manage: Docker-Compose-Projekte nativ per Pull, Up, Down oder Restart verwalten.
- synology_read_file / synology_write_file: .env- und docker-compose.yml-Konfigurationen remote bearbeiten.

🔒 Sicherheitshärtung (v1.1.0)

Schwachstelle	Lösung
Shell-Expansion bei Passwort (`$`, Backticks)	`echo "..."` durch `printf '%s\n' '...'` ersetzt, um Shell-Expansion zu verhindern
Befehlsinjektion (Container-/Projektname/Pfad-Konkatenation)	Alle Benutzereingaben werden vor der Shell-Konkatenation mit `shQuote()` umschlossen
Nicht validierter `action`-Parameter	Whitelist-Validierung auf Code-Ebene, unabhängig vom Schema-Enum
Pfad-Traversal (z. B. Lesen von `/etc/shadow`)	`synology_read_file` / `synology_write_file` auf `NAS_DOCKER_DIR` beschränkt; Pfade mit `..`-Segmenten werden abgelehnt
`tail`-Parameter-Injektion	Erzwingung positiver Ganzzahlen, Obergrenze 10000, Standardwert 100
SSH-Verbindung hängt unendlich	`readyTimeout: 30000` hinzugefügt

🚀 Einrichtungsanleitung

SSH auf dem Synology NAS aktivieren: Gehen Sie zu Systemsteuerung -> Terminal & SNMP und aktivieren Sie SSH-Dienst aktivieren.

Anmeldedaten konfigurieren: Kopieren Sie .env.example nach .env und geben Sie Ihre NAS-Verbindungsdetails ein:

NAS_HOST=192.168.1.xxx
NAS_PORT=22
NAS_USER=your_admin_account
NAS_PASSWORD=your_admin_password
NAS_DOCKER_DIR=/volume1/docker

Abhängigkeiten installieren & bauen:
```
npm install
npm run build
```

Mit MCP-Client verbinden (z. B. Claude Desktop / Cursor): Fügen Sie Folgendes zu Ihrer MCP-Konfigurations-JSON hinzu:

{
  "mcpServers": {
    "synology-docker": {
      "command": "node",
      "args": [
        "--env-file=e:\\Dev\\Synology Docker MCP\\.env",
        "e:\\Dev\\Synology Docker MCP\\build\\index.js"
      ]
    }
  }
}

Available Tools

7 tools

synology_docker_logsB

Get logs for a specific docker container

ParametersJSON Schema

Name	Required	Description	Default
`container_name`	Yes	Name or ID of the container
`tail`	No	Number of lines to show from the end of the logs

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description must bear full burden. It states 'Get logs' (read-only implied) but does not disclose whether actions are destructive, required permissions, or output details. Minimal transparency beyond the schema.

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?

Very concise single sentence, front-loaded with key action. Efficient, but arguably too short to fully inform the agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two parameters and no output schema, the description is minimally adequate. Lacks mention of output format, log origin, or caveats. Sibling context is not leveraged.

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 has 100% description coverage for both parameters, so baseline is 3. The description adds no extra meaning beyond what the schema provides.

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

Purpose5/5

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

The description clearly states the verb 'Get' and resource 'logs for a specific docker container'. It distinguishes from sibling tools like synology_docker_manage (manage containers) and synology_docker_ps (list containers).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Does not mention that synology_docker_ps lists containers or that synology_docker_manage handles container lifecycle. Implied usage only.

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

synology_docker_manageC

Manage container lifecycle (start, stop, restart)

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	Action to perform
`container_name`	Yes	Name or ID of the container

TDQS

C2.6/5.0

Behavior2/5

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

No annotations present, and the description does not disclose behavioral traits such as destructive actions (e.g., container removal) or required permissions. The description offers no additional detail beyond the basic action list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (one sentence) but incomplete because it omits the 'rm' action. Conciseness is not helpful if it sacrifices accuracy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two fully described parameters, the description is minimally adequate. However, it lacks mention of return values, error conditions, and the omitted 'rm' action, so completeness is moderate.

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?

Input schema has 100% description coverage, so the schema defines parameter semantics sufficiently. The description adds no extra meaning beyond what the schema already provides.

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

Purpose3/5

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

Description states 'manage container lifecycle' and lists three actions, but the input schema includes a fourth action 'rm' not mentioned. This omission reduces clarity and completeness.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to use this tool versus siblings like synology_docker_logs or synology_docker_ps. Context about prerequisites or appropriate scenarios is absent.

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

synology_docker_psA

List all docker containers on the Synology NAS

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, but it is minimal. It states a simple read-only listing without side effects, which is sufficient. However, it could mention that it is non-destructive or describe the output format. It meets the minimum for a straightforward tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, clear sentence that front-loads the core purpose. No unnecessary words, perfectly concise for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool with no parameters and no output schema, the description is adequate but not complete. It does not mention what information is returned (e.g., container names, statuses), which could be helpful for an agent. However, it is not severely lacking given the tool's trivial nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, so schema coverage is 100% by default. The description does not need to add parameter meaning. According to guidelines, 0 parameters yields a baseline score of 4.

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

Purpose5/5

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

The description clearly states the action (list), the resource (docker containers), and the context (on Synology NAS). It effectively distinguishes from sibling tools like synology_docker_logs and synology_docker_manage, which handle different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus its siblings. There is no mention of alternatives or context that would help an agent decide between this and other docker-related tools.

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

synology_project_listB

List docker-compose projects in the Synology NAS docker directory

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states the basic function without disclosing behavioral traits such as authentication needs, rate limits, or whether it is a read-only operation. The description does not contradict annotations as there are none.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no unnecessary words. It is front-loaded and efficiently conveys the function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should explain what the output contains (e.g., project names, details). It does not, leaving ambiguity about the return value. The tool is simple, but the description is incomplete in this regard.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist in the schema, and schema coverage is 100%. The description does not need to add parameter information. Baseline for 0 parameters is 4.

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

Purpose5/5

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

The description clearly states the verb 'list' and the resource 'docker-compose projects', and specifies the location 'in the Synology NAS docker directory'. It distinguishes itself from sibling tools like synology_docker_ps (which lists containers) and synology_project_manage (which manages projects).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no prerequisites or conditions mentioned. The description only states what it does without any usage context.

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

synology_project_manageB

Manage a docker-compose project (up, down, restart)

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes	Name of the project folder in NAS_DOCKER_DIR
`action`	Yes	Docker compose action

TDQS

B3.3/5.0

Behavior3/5

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

Lacks disclosure of side effects (e.g., down destroys containers), return behavior, or potential risks. With no annotations, burden is on description, but only actions are listed.

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?

Single sentence, no fluff. Could benefit from slightly more structure, but efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, and description does not explain return values or success/failure indicators. Incomplete for a management command that may produce logs or status.

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%, and descriptions for parameters are provided. The description does not add extra meaning beyond the schema; actions are repeated from enum values.

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

Purpose5/5

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

Clearly states verb 'Manage' and resource 'docker-compose project', lists specific actions (up, down, restart, pull). Distinguishes from siblings like synology_docker_manage and synology_docker_ps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives such as synology_docker_manage or synology_docker_ps. Does not specify prerequisites or context.

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

synology_read_fileB

Read a configuration file from the NAS (restricted to /volume1/docker)

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes	Absolute path to the file on the NAS (must be within /volume1/docker)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description has the full burden. It only reveals the path restriction but omits other behaviors like what happens if the file is missing or permissions issues.

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?

The description is a single concise sentence that conveys the essential constraint. It is front-loaded and efficient, though could add slightly more detail without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description is adequate but lacks details on return type or error conditions. Given the simplicity, it meets a minimum viable completeness.

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 description coverage is 100% and already explains the 'filepath' parameter fully. The tool description adds no additional parameter meaning beyond the schema.

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

Purpose5/5

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

The description clearly states the action 'Read' and the resource 'configuration file' with an explicit restriction 'restricted to /volume1/docker'. This distinguishes it from sibling tools like synology_write_file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives. No context about prerequisites, when not to use, or comparison with siblings.

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

synology_write_fileA

Write or update a configuration file on the NAS (restricted to /volume1/docker)

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes	Absolute path to the file on the NAS (must be within /volume1/docker)
`content`	Yes	File content to write

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, and the description only says 'Write or update' without disclosing whether it overwrites, appends, creates, or any permissions or error behavior. The description fails to add value beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise, front-loaded, and contains no fluff. Every word earns its place.

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?

Given the simplicity of the tool (2 parameters, no output schema), the description is fairly complete. It could mention whether it overwrites or appends, but the current level is adequate for a configuration file write.

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 description coverage is 100%, so the schema sufficiently documents both parameters. The description adds no additional semantics beyond what the schema already provides.

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

Purpose5/5

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

The description clearly states the verb (Write or update), the resource (configuration file), and the scope (restricted to /volume1/docker). It distinguishes from sibling tools like synology_read_file.

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?

The description implies use for configuration files within a restricted path, providing clear context. However, it does not explicitly state when to use or not use this tool versus alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv1.0.0May 2, 2026
- First observedsynology_docker_logs
- First observedsynology_docker_manage
- First observedsynology_docker_ps
- First observedsynology_project_list
- First observedsynology_project_manage
- First observedsynology_read_file
- First observedsynology_write_file

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool targets a distinct operation: container logs, lifecycle, listing; project listing, lifecycle; file read/write. No overlap in functionality.

Naming Consistency4/5

All tools share the 'synology_' prefix, but verb placement varies: some are verb_noun (synology_read_file) while others are noun_verb (synology_docker_logs). Mostly consistent with minor deviations.

Tool Count5/5

7 tools cover the essential Docker and project management operations without being excessive or sparse. Well-scoped for a NAS-specific server.

Completeness4/5

Covers core container and project lifecycle, logs, and file editing. Minor gaps like lack of image management or detailed inspect, but adequate for typical use.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Docker Compose AuditOAuth
io.github.UnbearableDev
Security audit for docker-compose.yml — 25 checks: secrets, privileges, network, volumes, images.
Security Developer Tools Testing & QA Tools
2
Railway MCPOAuth
com.railway
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Cloud Platforms Developer Tools CI/CD & DevOps
2
mcp AOAuth
dev.aicommander
Remote shell and detached long-running jobs on your own machines — no SSH, open ports or VPN.
Shell Access Command Line OS Automation
2
Dockerfile AuditOAuth
io.github.UnbearableDev
Hadolint-grade Dockerfile audit — 19 checks: secrets, privileges, supply chain, hygiene.
Code Analysis Security
2

Related MCP Servers

Docker MCP
Virtualization Command Line
Isak-Landin
A
license
Not graded
quality
D
maintenance
Enables remote Docker management over SSH via a local MCP server, providing tools to manage containers, images, Compose, and system resources.
Updated 4 months ago (2026-05-03 02:20 UTC)
1
GPL 3.0
QNAP Container Station MCP
Virtualization Developer Tools
baekhoej
A
license
Not graded
quality
C
maintenance
Enables managing Docker containers and Compose apps on a QNAP NAS via the Container Station API, including starting, stopping, restarting, and inspecting containers and applications.
Updated 4 months ago (2026-04-24 14:02 UTC)
6
MIT
dokploy-logs
misho85
-
license
Not graded
quality
Not graded
maintenance
Enables reading Docker container logs and stats from remote servers via SSH, supporting container listing, log retrieval, stats, inspection, and Docker Compose logs.
Updated 8 months ago (2026-01-17 12:14 UTC)
-
mcp-remote-docker
Virtualization CI/CD & DevOps File Systems
luisf371
F
license
Not graded
quality
D
maintenance
Manages Docker containers, images, and Compose stacks on a remote host over SSH, with file sync and deploy orchestration.
Updated 6 months ago (2026-03-18 05:24 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hifishhe/Synology-Docker-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server