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 서버

(영어 버전은 아래로 스크롤하세요 / Scroll down for English version)

🇨🇳 中文说明 (중국어 버전)

이 서버는 Synology NAS를 위해 특별히 설계된 Model Context Protocol (MCP) 서버입니다. 대규모 언어 모델(LLM)을 통해 Synology Container Manager 내의 Docker 컨테이너와 Docker Compose 프로젝트를 직접 관리, 구성 및 디버깅하는 것을 목표로 합니다.

✨ 핵심 기능 및 장점

SSH 기반 보안 관리: SSH를 통해 Synology NAS와 직접 통신하여 네이티브 명령을 안전하게 실행하며, Docker TCP 인터페이스를 외부에 노출할 위험을 완전히 제거합니다.
자동 권한 상승 (Auto-Privilege Escalation): 자격 증명을 자동으로 주입하여 sudo를 조용히 실행함으로써, Synology 관리자 계정이 docker 실행 시 흔히 겪는 Permission Denied 권한 문제를 완벽하게 해결합니다.
Synology Container Manager 완벽 호환: docker-compose -p 태그를 기본적으로 지원하고 강제하여, 이 MCP 서버를 통해 시작하거나 업데이트된 프로젝트가 Synology 웹 인터페이스의 프로젝트 목록과 완벽하게 동기화되도록 합니다(녹색 상태 표시 유지).
포괄적인 도구 세트:
- synology_docker_ps: 실행 중인 모든 컨테이너 확인.
- synology_docker_logs: 컨테이너 로그 가져오기 및 추적.
- synology_docker_manage: 컨테이너 시작, 중지, 재시작 또는 제거 제어.
- synology_project_list: /volume1/docker/ 디렉토리 내의 모든 프로젝트 자동 검색 및 발견.
- synology_project_manage: 프로젝트의 Pull, Up, Down 또는 Restart 명령을 네이티브로 실행.
- synology_read_file / synology_write_file: .env 및 docker-compose.yml 구성 파일을 원격으로 읽거나 수정.

🔒 보안 강화 기록 (v1.1.0)

취약점	해결 방안
비밀번호 특수 문자 확장 (`$`/백틱)	`echo "..."`를 `printf '%s\n' '...'`로 변경하여 셸 확장 방지
명령 주입 (컨테이너명/프로젝트명/경로 결합)	모든 사용자 입력은 `shQuote()`로 단일 인용 부호 처리 후 명령 결합
action 매개변수 미검증	스키마 enum과 독립적으로 코드 수준에서 화이트리스트 검증
경로 탐색 (`/etc/shadow` 등)	`synology_read_file` / `synology_write_file`을 `NAS_DOCKER_DIR` 내로 제한, `..`이 포함된 경로 거부
`tail` 매개변수 주입	양의 정수로 강제, 상한선 10000, 기본값 100
SSH 연결 타임아웃 없음	`readyTimeout: 30000` 추가

🚀 빠른 시작 구성

Synology SSH 서비스 활성화: 제어판 -> 터미널 및 SNMP로 이동하여 SSH 서비스 활성화를 체크합니다.
환경 변수 자격 증명 구성: 프로젝트의 .env.example을 복사하여 .env로 이름을 변경하고 NAS 연결 정보를 입력합니다:
```
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 install
npm run build
```

MCP 클라이언트 연결 (예: Claude Desktop 또는 Cursor): 다음 내용을 클라이언트의 MCP 구성 JSON에 추가합니다:

{
  "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

🇬🇧 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.
Synology Container Manager Compatibility: Native support for docker-compose -p, ensuring that projects started or updated via this MCP server perfectly align with the Synology Container Manager GUI (maintaining the green status indicator).
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 projects mapped in /volume1/docker/.
- synology_project_manage: Pull, up, down, or restart Docker Compose projects natively.
- 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): Add the following to your MCP configuration JSON:

{
  "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