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

(Scroll down for English version / 英文版本在下方)

🇨🇳 中文说明 (Chinese Version)

这是一个专门为群晖 (Synology NAS) 设计的 Model Context Protocol (MCP) 服务器。它旨在通过大语言模型直接管理、配置和调试群晖 Container Manager 中的 Docker 容器和 Docker Compose 项目。

✨ 核心功能与亮点

基于 SSH 的安全管理: 直接通过 SSH 与您的群晖 NAS 进行通信，安全执行原生命令，彻底免除对外暴露 Docker TCP 接口的风险。
自动提权系统 (Auto-Privilege Escalation): 自动注入凭证静默执行 sudo，完美解决群晖管理员账号在执行 docker 时常见的 Permission Denied 权限壁垒。
DSM Container Manager 原生 Project 控制面: 对 DSM 创建/管理的 Project，通过 SYNO.Docker.Project 调用原生 Project API；不再将普通 docker-compose wrapper 视为 DSM Project 控制面。
全方位工具集:
- synology_docker_ps: 查看所有运行中的容器。
- synology_docker_logs: 获取并追踪容器日志。
- synology_docker_manage: 控制容器的启动、停止、重启或移除。
- synology_project_list: 自动搜索并发现 /volume1/docker/ 目录下的 Compose 项目。
- synology_project_manage: 仅限非 DSM 管理项目的 legacy docker-compose wrapper；不得用于 Container Manager Project。
- synology_dsm_project_list / synology_dsm_project_log: 读取 DSM 原生 Project registry 和操作日志。
- synology_dsm_container_list: 读取 DSM Container Manager 的容器名称/ID 映射。
- synology_dsm_project_manage: 对 DSM Project 执行 build_stream、start_stream、stop_stream 或 restart_stream；刻意不暴露 clean / delete。
- synology_read_file / synology_write_file: 远程读取或修改 .env 与 docker-compose.yml 配置文件。

🔒 安全加固记录 (v1.1.0)

漏洞	修复方案
密码特殊字符展开（`$`/反引号）	`echo "..."` 改为 `printf '%s\n' '...'`，避免 shell 展开
命令注入（容器名/项目名/路径拼接）	所有用户输入经 `shQuote()` 单引号包裹后再拼接命令
action 参数未验证	代码层白名单校验，独立于 schema enum
路径遍历（`/etc/shadow` 等）	`synology_read_file` / `synology_write_file` 限制在 `NAS_DOCKER_DIR` 内，拒绝含 `..` 的路径
`tail` 参数注入	强制正整数，上限 10000，默认 100
SSH 连接无超时	添加 `readyTimeout: 30000`

🚀 快速上手 (面向终端用户)

开启群晖 SSH 服务: 前往 控制面板 -> 终端机和 SNMP 并勾选 启动 SSH 功能。

接入 MCP 客户端 (例如 Claude Desktop 或 Cursor): 您不需要克隆代码或安装任何东西。只需将以下内容添加到客户端的 MCP 配置文件 JSON 中，客户端会自动通过 npx 帮您拉取并运行最新版代码：

{
  "mcpServers": {
    "synology-docker": {
      "command": "npx",
      "args": [
        "-y",
        "synology-docker-mcp"
      ],
      "env": {
        "NAS_HOST": "192.168.1.xxx",
        "NAS_PORT": "22",
        "NAS_USER": "your_admin_account",
        "NAS_PASSWORD": "your_admin_password",
        "NAS_DOCKER_DIR": "/volume1/docker"
      }
    }
  }
}

🛠️ 本地开发 (面向开发者)

如果您希望修改此项目的源代码：

克隆并配置: 复制项目中的 .env.example 并重命名为 .env，填入您的 NAS 连接信息。
安装依赖并构建:
```
npm install
npm run build
```
测试运行:
```
npm start
```

📦 npm 发布（维护者）

项目通过 GitHub Actions 的 npm Trusted Publishing 发布，不保存长期 npm token。首次发布前，在 npm 包设置中添加 trusted publisher：

Repository: hifishhe/Synology-Docker-MCP
Workflow filename: publish-npm.yml

之后在 GitHub Actions → Publish npm package → Run workflow 中输入要发布的 tag（例如 v1.0.2）。以后推送新的 v* tag 会自动触发发布。

Related MCP server: QNAP Container Station MCP

🇬🇧 English Version

This is a Model Context Protocol (MCP) server specifically designed to manage, configure, and debug Docker containers and Docker Compose projects on Synology NAS devices.

✨ Features & Highlights

SSH-Based Management: Communicates with your Synology NAS directly via SSH, ensuring secure execution of native commands without needing to expose the Docker TCP socket.
Auto-Privilege Escalation: Automatically injects credentials to run sudo silently, bypassing the Permission Denied issues commonly faced by Synology administrator accounts.
DSM Container Manager Native Project Control Plane: DSM-created or DSM-managed Projects are operated through the native SYNO.Docker.Project API. A plain docker-compose wrapper is not treated as DSM Project control.
Comprehensive Toolset:
- synology_docker_ps: View all running containers.
- synology_docker_logs: Stream container logs.
- synology_docker_manage: Start, stop, restart, or remove containers.
- synology_project_list: Discover Compose projects under /volume1/docker/.
- synology_project_manage: Legacy docker-compose wrapper for non-DSM-managed projects only; never use it for a Container Manager Project.
- synology_dsm_project_list / synology_dsm_project_log: Read the native DSM Project registry and action log.
- synology_dsm_container_list: Read DSM Container Manager's displayed container name-to-ID mapping.
- synology_dsm_project_manage: Run build_stream, start_stream, stop_stream, or restart_stream for a DSM Project; clean and delete are intentionally unavailable.
- synology_read_file / synology_write_file: Edit .env and docker-compose.yml configurations remotely.

🔒 Security Hardening (v1.1.0)

Vulnerability	Fix
Password shell expansion (`$`, backticks)	Replaced `echo "..."` with `printf '%s\n' '...'` to prevent shell expansion
Command injection (container/project name/path concatenation)	All user inputs wrapped with `shQuote()` before shell concatenation
Unvalidated `action` parameter	Code-level whitelist enforced independently of schema enum
Path traversal (e.g. reading `/etc/shadow`)	`synology_read_file` / `synology_write_file` restricted to `NAS_DOCKER_DIR`; paths with `..` segments rejected
`tail` parameter injection	Enforced positive integer, capped at 10000, defaults to 100
SSH connection hangs indefinitely	Added `readyTimeout: 30000`

🚀 Setup Instructions

Enable SSH on Synology NAS: Go to Control Panel -> Terminal & SNMP and check Enable SSH service.

Configure Credentials: Copy .env.example to .env and fill in your NAS connection details:

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

Install Dependencies & Build:
```
npm install
npm run build
```

Connect to MCP Client (e.g. Claude Desktop / Cursor): While you can use a local node path if built locally, the highly recommended method is to use npx (which pulls directly from npm, requiring no local cloning). Add the following to your MCP configuration JSON:

{
  "mcpServers": {
    "synology-docker": {
      "command": "npx",
      "args": [
        "-y",
        "synology-docker-mcp"
      ],
      "env": {
        "NAS_HOST": "192.168.1.xxx",
        "NAS_PORT": "22",
        "NAS_USER": "your_admin_account",
        "NAS_PASSWORD": "your_admin_password",
        "NAS_DOCKER_DIR": "/volume1/docker"
      }
    }
  }
}

📦 npm Publishing (Maintainers)

This project uses GitHub Actions npm Trusted Publishing and stores no long-lived npm token. Before the first publication, add a trusted publisher in the npm package settings:

Repository: hifishhe/Synology-Docker-MCP
Workflow filename: publish-npm.yml

Then run Actions → Publish npm package → Run workflow and enter the tag to publish (for example v1.0.2). Future v* tags trigger publishing automatically.

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