Skip to main content
Glama

docker_exec

Destructive

Run commands inside a Docker Compose service container and retrieve the exit code with stdout and stderr kept separate. Destructive commands are blocked until confirmed.

Instructions

Runs a command inside a service container and brings back its exit code, with stdout and stderr apart. exit_code null means the command never ran and reason says why; an empty stdout means it ran and said nothing. What destroys data is refused until the command carries # CONFIRMED-DESTRUCTIVE. Reading logs, asking a database and taking dumps have tools of their own.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userNoRun as this user instead of the one the image declares. Default: the image user.
commandYesThe command line as it would be typed inside the container: "npm test", "alembic upgrade head". What destroys data — wiping a directory, dropping files — is refused until the line carries # CONFIRMED-DESTRUCTIVE.
profileNoWhich Docker host, by profile name. Default: the profile marked as default.
projectNoWhich compose project. Default: the project of the working directory. A name matching nothing is an error, not a fall back to every container on the host.
serviceYesService name as written in the compose file.
workdirNoWhere inside the container the command runs. Default: working_dir of this service in the compose file, and the directory of the image where the file names none.
interactiveNoGive the command a terminal. Both streams then arrive merged in stdout with stderr empty, and nothing is sent to its input: one call is not a dialogue. Default: false.
compose_pathNoWhere the compose file is: the file itself, or the directory holding it. Needed only when no container of the host carries the project label — a project that was never brought up there. A directory holding several compose files is refused with their names rather than guessed through.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
legendNoWhat the words in this answer mean. A key names the field before the value — "state=running", "containers[].health=unhealthy" — and only the values this answer used are listed.
reasonNo
stderrNo
stdoutNo
commandNo
projectNo
serviceNo
warningsNo
exit_codeNo
truncatedNo
clipped_bytesNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv2.0.1

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description explains that destructive commands are refused until they carry '# CONFIRMED-DESTRUCTIVE', and clarifies the exit_code null and empty stdout semantics. These are meaningful behavioral details not present in the annotations or schema.

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 compact and front-loaded with the core action and result, then covers output semantics, safety, and alternatives in a few tight sentences. Every sentence earns its place with no redundant filler.

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

Completeness5/5

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

Given the high schema coverage, the output schema, and annotations, the description covers the essential non-obvious context: exit code null meaning, empty stdout meaning, the destructive-command guard, and the boundary with sibling tools. No critical gap remains for a tool this complex.

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 already documents all parameters. The description adds general behavioral context about commands and output, but it does not materially deepen parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate.

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 names a specific verb ('runs a command'), a specific resource ('inside a service container'), and its key outcome ('brings back its exit code, with stdout and stderr apart'). It also differentiates from siblings by pointing out that logs, database queries, and dumps have dedicated tools.

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 gives useful context for when to use this tool versus alternatives: reading logs, asking a database, and taking dumps are explicitly routed elsewhere. It also explains the destructive-command refusal mechanism. However, it does not name the exact sibling tools or spell out a crisp when-not-to-use condition beyond those categories.

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

Latest Blog Posts

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/hypnosis/docker-mcp-server'

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