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 / 英語版は以下にあります)

🇨🇳 中文说明 (中国語版)

これは、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のWeb管理画面上のプロジェクトインターフェースと完全に同期（緑色の正常ステータスを維持）されることを保証します。
包括的なツールセット:
- 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