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

Servidor MCP de Docker para Synology

(Desplácese hacia abajo para la versión en inglés / English version below)

🇨🇳 中文说明 (Versión en chino)

Este es un servidor del Protocolo de Contexto de Modelo (MCP) diseñado específicamente para Synology NAS. Su objetivo es gestionar, configurar y depurar directamente contenedores Docker y proyectos Docker Compose en el Container Manager de Synology a través de modelos de lenguaje grandes.

✨ Funciones principales y aspectos destacados

Gestión segura basada en SSH: Se comunica directamente con su NAS Synology a través de SSH, ejecutando comandos nativos de forma segura y eliminando por completo el riesgo de exponer la interfaz TCP de Docker al exterior.
Sistema de escalada automática de privilegios (Auto-Privilege Escalation): Inyecta credenciales automáticamente para ejecutar sudo de forma silenciosa, resolviendo perfectamente la barrera de permisos Permission Denied que suelen encontrar las cuentas de administrador de Synology al ejecutar docker.
Compatibilidad perfecta con Synology Container Manager: Soporte nativo y uso forzado de la etiqueta docker-compose -p, asegurando que los proyectos iniciados o actualizados a través de este servidor MCP puedan sincronizarse perfectamente con la interfaz de proyectos de la web nativa de Synology (manteniendo el estado de salud del punto verde).
Conjunto de herramientas integral:
- synology_docker_ps: Ver todos los contenedores en ejecución.
- synology_docker_logs: Obtener y rastrear registros de contenedores.
- synology_docker_manage: Controlar el inicio, detención, reinicio o eliminación de contenedores.
- synology_project_list: Buscar y descubrir automáticamente todos los proyectos en el directorio /volume1/docker/.
- synology_project_manage: Ejecutar instrucciones nativas de Pull, Up, Down o Restart para proyectos.
- synology_read_file / synology_write_file: Leer o modificar de forma remota los archivos de configuración .env y docker-compose.yml.

🔒 Registro de refuerzo de seguridad (v1.1.0)

Vulnerabilidad	Solución
Expansión de caracteres especiales en contraseñas (`$`/backticks)	Se cambió `echo "..."` por `printf '%s\n' '...'` para evitar la expansión del shell
Inyección de comandos (concatenación de nombre de contenedor/proyecto/ruta)	Todas las entradas del usuario se envuelven con `shQuote()` antes de concatenar el comando
Parámetro de acción no validado	Validación de lista blanca a nivel de código, independiente del enum del esquema
Recorrido de rutas (como `/etc/shadow`)	`synology_read_file` / `synology_write_file` restringidos a `NAS_DOCKER_DIR`, rechazando rutas que contengan `..`
Inyección de parámetros en `tail`	Entero positivo forzado, límite superior de 10000, predeterminado en 100
Conexión SSH sin tiempo de espera	Se añadió `readyTimeout: 30000`

🚀 Configuración rápida

Habilitar el servicio SSH de Synology: Vaya al Panel de control -> Terminal y SNMP y marque Habilitar servicio SSH.
Configurar las credenciales de variables de entorno: Copie el archivo .env.example del proyecto y cámbiele el nombre a .env, introduciendo la información de conexión de su 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
```
Instalar dependencias y compilar:
```
npm install
npm run build
```

Conectar al cliente MCP (por ejemplo, Claude Desktop o Cursor): Añada el siguiente contenido al archivo JSON de configuración MCP del cliente:

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

🇬🇧 Versión en inglés

Este es un servidor del Protocolo de Contexto de Modelo (MCP) diseñado específicamente para gestionar, configurar y depurar contenedores Docker y proyectos Docker Compose en dispositivos NAS Synology.

✨ Características y aspectos destacados

Gestión basada en SSH: Se comunica con su NAS Synology directamente a través de SSH, asegurando la ejecución segura de comandos nativos sin necesidad de exponer el socket TCP de Docker.
Escalada automática de privilegios: Inyecta credenciales automáticamente para ejecutar sudo de forma silenciosa, evitando los problemas de Permission Denied que suelen enfrentar las cuentas de administrador de Synology.
Compatibilidad con Synology Container Manager: Soporte nativo para docker-compose -p, asegurando que los proyectos iniciados o actualizados a través de este servidor MCP se alineen perfectamente con la GUI de Synology Container Manager (manteniendo el indicador de estado verde).
Conjunto de herramientas integral:
- synology_docker_ps: Ver todos los contenedores en ejecución.
- synology_docker_logs: Transmitir registros de contenedores.
- synology_docker_manage: Iniciar, detener, reiniciar o eliminar contenedores.
- synology_project_list: Descubrir proyectos mapeados en /volume1/docker/.
- synology_project_manage: Ejecutar de forma nativa Pull, Up, Down o Restart en proyectos de Docker Compose.
- synology_read_file / synology_write_file: Editar configuraciones de .env y docker-compose.yml de forma remota.

🔒 Refuerzo de seguridad (v1.1.0)

Vulnerabilidad	Solución
Expansión de shell en contraseñas (`$`, backticks)	Se reemplazó `echo "..."` por `printf '%s\n' '...'` para evitar la expansión del shell
Inyección de comandos (concatenación de nombre de contenedor/proyecto/ruta)	Todas las entradas del usuario se envuelven con `shQuote()` antes de la concatenación del shell
Parámetro `action` no validado	Lista blanca a nivel de código aplicada independientemente del enum del esquema
Recorrido de rutas (ej. lectura de `/etc/shadow`)	`synology_read_file` / `synology_write_file` restringidos a `NAS_DOCKER_DIR`; se rechazan rutas con segmentos `..`
Inyección de parámetros en `tail`	Entero positivo forzado, limitado a 10000, predeterminado en 100
La conexión SSH se bloquea indefinidamente	Se añadió `readyTimeout: 30000`

🚀 Instrucciones de configuración

Habilitar SSH en el NAS Synology: Vaya a Panel de control -> Terminal y SNMP y marque Habilitar servicio SSH.

Configurar credenciales: Copie .env.example a .env y rellene los detalles de conexión de su 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

Instalar dependencias y compilar:
```
npm install
npm run build
```

Conectar al cliente MCP (ej. Claude Desktop / Cursor): Añada lo siguiente a su JSON de configuración de MCP:

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