dockerbro

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct Docker resource and action. Container management tools (list, inspect, start, stop, restart, remove, logs, exec, run) are clearly separated from image tools (list, pull, remove) and compose tools (up, down, logs, ps). No two tools have overlapping purposes.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., list_containers, start_container, remove_image). The Docker Compose tools consistently use a docker_compose_ prefix with a verb suffix, which is a slight deviation from the main pattern but remains predictable and internally consistent.
Tool Count5/5
With 16 tools, the server is well-scoped for Docker management. Each tool covers a distinct operation, and the count is appropriate for handling containers, images, and Compose workflows without being overwhelming or sparse.
Completeness4/5
The tool set covers the core Docker lifecycle: container run/start/stop/restart/remove/logs/exec, image list/pull/remove, and Compose up/down/logs/ps. Missing operations like image build/push or container stats are notable but not critical for common workflows, allowing agents to work around the gaps.
Average 3.3/5 across 16 of 16 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation, but it adds no additional behavioral context. It does not mention default tail behavior, whether logs are returned for all services if no service is specified, or any dependencies like project_dir. Beyond the safe-read annotation, the description offers minimal value.
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 sentence containing only essential words, making it highly concise and front-loaded. There is no unnecessary verbosity, though the brevity also contributes to the lack of detail noted in other dimensions.
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?
The tool has moderate complexity with three parameters and a sibling 'logs_container' that overlaps in functionality. The description does not clarify the project directory requirement, the default scope of logs, or how this differs from 'logs_container'. Given the sparse schema and absence of an output schema, the description is too incomplete for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 33%, with just 'tail' having a description. The tool description does not explain the 'service' or 'project_dir' parameters, nor does it clarify defaults or behavior. Given the low schema coverage, the description fails to compensate and leaves parameter meanings ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Docker Compose service logs.' clearly states the verb (Get) and resource (Docker Compose service logs), making the tool's purpose obvious. However, it does not explicitly differentiate from the sibling 'logs_container' or other compose-related tools, so it falls short of a perfect score.
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 alternatives such as 'logs_container' or 'docker_compose_ps'. There is no mention of scenarios, exclusions, or selection criteria, leaving the agent without context for choosing correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the idempotentHint annotation, the description adds no behavioral context. It doesn't disclose that restart typically stops then starts a container, or what happens if the container doesn't exist. The annotation covers idempotency, but other behavioral traits are omitted.
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, clear sentence with no unnecessary words. It is appropriately minimal for a straightforward operation, and the structure is perfectly concise.
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 the tool's simplicity (1 parameter, no output schema) and the annotation, the description is minimally sufficient for a basic operation but lacks critical contextual info. It doesn't explain implications (e.g., stopping/starting), potential errors, or when to prefer this over stop/start. The presence of many sibling tools and no additional explanation makes it incomplete for an AI agent to choose correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. The only parameter 'container' is a string with no explanation in either the schema or the description. The phrase 'Restart a container' implies the 'container' argument but gives no details about format, valid values, or meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Restart a container' clearly states the action (restart) and the resource (container). It distinguishes from sibling tools like start_container and stop_container because 'restart' implies a distinct operation. However, it lacks explicit detail such as 'stop and start' which could add clarity.
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 alternatives like start_container or stop_container. There are no usage scenarios, exclusions, or mentions of related tools despite many siblings being available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation idempotentHint=true is present, but the description adds no extra behavioral context. It does not disclose whether stopping is graceful, how it affects the container's state, or any side effects. The description is purely literal and relies entirely on the annotation for behavioral safety.
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, well-structured and front-loaded with the key action. It wastes no words, though it offers minimal substance beyond the statement of purpose.
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 the simple one-parameter schema and no output schema, the description is too sparse. It omits important context such as what happens to the container after stopping, how it relates to remove_container, and whether any arguments are needed for force stopping. The description alone provides barely enough information for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines only one parameter 'container' with type string, and description coverage is 0%. The description does not explain what the container parameter refers to (e.g., ID, name, or pattern), so the schema is insufficient and the description fails to compensate.
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 tool stops a container, using the specific verb "stop" and resource "container". It distinguishes from sibling tools like start_container, restart_container, and remove_container, making the purpose unambiguous.
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 is provided on when to use this tool versus alternatives such as restart_container or remove_container. There is no mention of prerequisites, excluded scenarios, or preference over other lifecycle commands, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds little beyond the readOnlyHint annotation. It doesn't disclose output format, error behavior, or the specific details returned, giving the agent no additional behavioral context beyond knowing it's a read operation.
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 front-loads the action, making it easily scannable. However, it is very terse and could include additional useful context without becoming verbose.
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?
With no output schema and a minimal description, the agent lacks insight into what 'detailed info' includes (e.g., JSON config, state). Given the presence of sibling tools with distinct purposes, a bit more context would be necessary for confident selection.
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?
The input schema already fully describes the 'container' parameter with type and description, and schema coverage is 100%. The tool description adds no parameter-specific meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and specifies the resource 'detailed info about a container,' clearly indicating a read-only inspection operation. It distinguishes from siblings like 'list_containers' and 'logs_container' by focusing on 'detailed info,' though it doesn't elaborate on what exactly that entails.
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 alternatives. It doesn't mention that 'list_containers' is for summaries or that 'logs_container' is for logs, leaving the agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Run a new container', implying each invocation creates a new resource, which directly contradicts the idempotentHint annotation (true) that claims the operation is idempotent. This is a significant behavioral contradiction, making the description misleading about the tool's actual behavior.
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 with no redundancy or filler. It is front-loaded and easy to parse. However, it is nearly a tautology of the tool name and lacks structured detail, so it is not a perfect 5.
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 the tool's complexity (6 parameters, no output schema, only a contradictory annotation), a one-line description is inadequate. It fails to describe return values, side effects like image pulling or port handling, or how parameters like detach and name affect behavior. The agent is left with an incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 50%, but the description adds no guidance for the undocumented parameters (name, image, command). The phrase 'from an image' only echoes the required image parameter, offering no additional meaning. The description fails to compensate for the schema gaps.
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 (Run) and resource (a new container from an image), which distinguishes it from sibling tools like start_container (starts an existing container) and remove_container (removes a container). It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this tool is for creating and running a new container from an image. However, it does not explicitly state when to use this tool instead of alternatives (e.g., start_container for existing containers) or mention prerequisites such as the image being available. The guidance is minimal but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description 'List' aligns with that. However, the description adds no additional behavioral details such as whether project_dir is optional, default behavior, or what output is returned. With annotations covering the safety profile, the description adds no extra value, scoring low.
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 redundant words. It is front-loaded and efficiently states the action.
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?
Given the simple tool and read-only annotation, the description is minimal but lacks information about return format and usage scenarios. Since no output schema exists, the description should provide more detail about what the output contains, such as service names and status, to be fully complete.
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?
The schema fully describes the single parameter project_dir with the description 'Directory with docker-compose.yml', giving 100% coverage. The tool description adds no additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List Docker Compose services' uses a specific verb and resource, clearly indicating the tool's function. It distinguishes from siblings like list_containers by specifying 'Compose services', though it doesn't explicitly contrast with them.
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 is provided about when to use this tool versus alternatives like list_containers or docker_compose_logs. The description only states the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the destructiveHint annotation. It does not disclose side effects, failure conditions (e.g., image in use), or irreversibility. The annotation already indicates destructiveness, but no extra value is added.
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 sentence with no unnecessary words. It is front-loaded and immediately states the action.
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?
While the tool is simple, the description is too minimal. It omits critical operational details such as what happens on success, whether dangling images are removed, and potential errors. The lack of an output schema or any behavioral caveats leaves the agent under-equipped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'image' parameter with no description, and the tool description does not explain what format to use (e.g., name, tag, or ID). With 0% schema coverage, the description should compensate but does not.
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 'Remove a Docker image' uses a specific verb and resource, clearly distinguishing it from sibling tools like remove_container and pull_image. It is immediately clear what the tool does.
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 is provided on when to use this tool or under what conditions. There is no mention of prerequisites, such as ensuring the image is not in use, or alternatives like force removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the idempotentHint annotation. It does not mention that 'detach' defaults to true, that 'build' triggers a build before starting, or any side effects like network/volume creation. With annotations present, the bar is lower, but the description still fails to disclose useful behavioral traits.
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 fluff. It is front-loaded and directly states the action, earning a perfect score for efficiency.
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 the tool has 4 parameters, no output schema, and sibling tools with overlapping functionality, the description is too terse. It lacks information about return values, behavior when services are already running, and the meaning of detach/build parameters. This leaves the agent under-informed for a reasonably complex operation.
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 75% (three of four parameters have descriptions), so the schema does most of the heavy lifting. The tool description adds no parameter-level information, leaving project_dir undocumented. Baseline 3 is appropriate as the description does not hinder but also does not enhance 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 'Start Docker Compose services' uses a specific verb and resource, clearly distinguishing it from siblings like docker_compose_down, docker_compose_logs, and start_container. The phrase 'Compose services' differentiates it from container-level 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?
No guidance is provided on when to use this tool versus alternatives such as start_container or docker_compose_down. The description lacks context about prerequisites, when to choose this over other tools, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states the prerequisite that the container is running, but does not mention stdout/stderr behavior, exit code handling, required permissions, or that it is equivalent to 'docker exec'. The description lacks side-effect or limitation information.
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, front-loaded sentence that clearly states the tool's purpose without any filler. Every word contributes meaning, making it highly concise and well-structured.
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 no output schema and no annotations, the description provides the core action and the running-container prerequisite, which is minimally adequate. However, it does not clarify how this differs from run_container or what happens if the container is not running, leaving some gaps for an agent selecting among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: 'command' has a vague description ('Command to run'), while 'container' has none. The tool description adds no extra meaning, such as whether container accepts names/IDs or whether command can include arguments. It does not compensate for the undocumented 'container' parameter.
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 'Execute a command inside a running container' clearly identifies the action (execute), the resource (container), and the prerequisite condition (running). This distinguishes it from sibling tools like run_container, which creates a new container, or start_container, which changes container state.
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 explicit guidance is given about when to use this tool versus alternatives such as run_container or docker_compose_exec. The description implies it is for an already-running container, but it does not say 'use this when you need to run a one-off command in an existing container' or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the obvious pull action. IdempotentHint is already provided by annotations, but the description does not mention side effects such as updating existing tags, requiring network access, or potential registry authentication issues.
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 wasted words. It is front-loaded with the verb and resource, making it immediately clear what the tool does.
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, the description is minimally adequate. The idempotent annotation and schema provide some context, but the description lacks usage guidance and behavioral nuances such as tag handling and registry dependencies, which could be valuable for an agent.
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% with a clear example for the 'image' parameter. The description does not add further parameter details, so the baseline score of 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 uses the specific verb 'pull' and clearly identifies the resource as 'a Docker image from a registry', which distinguishes it from sibling tools like list_images or remove_image. It states exactly what the tool does without ambiguity.
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 alternatives. It does not mention scenarios like pre-pulling images before running a container or checking existing images with list_images, leaving the agent without explicit context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation, and the description aligns with that. The description adds a minor scoping detail ('recent') but does not disclose any other behavioral aspects like whether logs are streamed, truncated, or in what format.
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 filler or redundancy. It is front-loaded with the action ('Get') and resource, making it immediately clear.
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?
The tool is simple, with read-only annotations and a basic schema, but the description lacks usage context and parameter meaning. It adequately identifies the primary function but leaves gaps around when to use it and what the return output looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: tail has a description in the schema, but container does not. The tool description does not compensate by explaining either parameter beyond the generic phrase 'from a container,' which merely repeats the parameter name. It fails to clarify the expected format or role of the container argument.
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 uses a specific verb ('Get') with a clear resource ('recent log output from a container'), which directly states what the tool does. It distinguishes itself from sibling tools like docker_compose_logs by specifying 'container' rather than compose services, and it's distinct from inspection or management commands.
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 alternatives such as docker_compose_logs or inspect_container. It does not mention exclusions, prerequisites, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'remove services', which provides some detail beyond the destructiveHint annotation by specifying what is affected. However, it does not add context about the volumes parameter's default behavior, potential idempotency (which is hinted by the annotation but not explained), or additional effects like removing networks. It is consistent with the annotations, so no contradiction.
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, front-loaded sentence that clearly communicates the core action. There is no redundant or filler content; every word earns its place.
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?
For a destructive tool with a barely documented parameter and no output schema, the description is insufficient. It does not explain the project_dir parameter, the default cleanup scope, or what 'services' entails in terms of containers/disks/networks. The agent would need to look at sibling tools or infer a lot.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: volumes has a description, but project_dir has none. The description does not mention project_dir at all, leaving its meaning ambiguous. It adds no value beyond the schema for volumes, and fails to compensate for the undocumented project_dir parameter.
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 tool's function with specific verbs ('Stop and remove') and resource ('Docker Compose services'). This distinguishes it from sibling tools like docker_compose_up (which starts services) and individual container commands such as stop_container or remove_container.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and the presence of docker_compose_up as a sibling: this is the inverse operation. However, the description does not explicitly state when to use it vs. alternatives, such as when to use stop_container for individual containers or the compose-specific scope. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation. The description adds the output fields (status, image, ports), which is useful context, but does not disclose any further behavioral details like pagination or formatting. This is adequate but not rich.
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 of seven words, front-loaded with the verb and resource, and every word adds value. No wasted words or redundant information.
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?
For a simple list tool with one parameter fully described in the schema, the description captures the core functionality and even lists output fields, which is helpful given the lack of an output schema. It does not mention the 'all' parameter, but that is covered in the schema, so the description is sufficiently complete.
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?
The schema description coverage is 100%, with the parameter 'all' fully documented. The tool description itself does not elaborate on parameters, but since the schema already covers them, a baseline of 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 clearly states the action (List) and the resource (Docker containers), and specifies the output fields (status, image, ports). This distinguishes it from sibling tools like list_images and inspect_container.
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 alternatives such as inspect_container or list_images. No exclusions or alternative tool mentions are present, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The idempotentHint annotation already signals safe retries. The description adds the constraint that the container must be stopped, but it does not mention what happens if the container is already running, permissions required, or side effects. Given the annotation, this is acceptable but not rich.
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, focused sentence that conveys the essential operation without any fluff or redundancy. It is appropriately sized for the simplicity of the tool.
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 start operation with one parameter and an idempotency annotation, the description is mostly adequate. However, the missing parameter format and lack of guidance on edge cases (e.g., already running) leave some gaps, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'container' parameter, and the description does not clarify whether it accepts a container ID, name, or both. Since the schema coverage is low, the description was expected to compensate but does not.
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 'Start a stopped container.' uses a specific verb ('start') and resource ('container') and further specifies the state ('stopped'), clearly distinguishing it from sibling tools like stop_container, restart_container, and run_container. It unambiguously identifies the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for starting containers that are currently stopped, but it does not explicitly state when to use this tool versus alternatives (e.g., run_container for new containers) or provide exclusions. The context is minimal, so it earns a mid-range score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds the 'local system' scope, which is helpful context beyond the annotation, but it does not disclose any additional behavioral traits such as output format, ordering, or filtering. This meets the baseline for annotation-covered tools but adds limited extra value.
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 that front-loads the action and resource. Every word contributes, with no redundancy or unnecessary detail.
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 tool's simplicity—no params, readOnlyHint annotation, and a clear purpose—the description is largely complete for an agent to select and invoke it. It explains what it lists and where. It doesn't detail the return format, but for a list operation this is often implied and not a critical gap.
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 tool has zero parameters, so the schema provides complete coverage with 100% schema description coverage. The description correctly omits parameter details as there are none. Baseline for 0 params is 4, and the description doesn't need to add anything.
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 uses a specific verb 'List' and identifies the resource 'Docker images' and scope 'local system', clearly distinguishing it from siblings like list_containers. It's unambiguous and directly states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (local system images) but does not explicitly mention when to use this tool over alternatives like list_containers or when to prefer pull_image/remove_image. No exclusions or alternative guidance is provided, leaving usage to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description complements the destructiveHint annotation by clarifying that the tool is designed for stopped containers, and force=true extends it to running containers. This adds behavioral context beyond the annotation without contradicting it.
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, front-loaded sentence that efficiently communicates the core operation and the key edge case (force for running containers). No wasted words.
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?
For a simple two-parameter tool with no output schema, the description covers the essential behavior and the conditional force usage. It could be slightly more explicit about error scenarios or removing volumes, but it's sufficient for an agent to invoke it correctly.
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 description adds meaning to the force parameter by specifying it's for running containers, which goes beyond the schema's brief 'Force remove'. The container parameter is self-explanatory from the name, though the description doesn't detail expected format.
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 'Remove' and the resource 'container', with an important qualifier 'stopped'. It distinguishes from siblings like remove_image, and the force option clarifies scope for running containers.
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?
Provides clear context: the tool removes stopped containers, and for running containers you must pass force=true. It implies when force is needed but doesn't explicitly mention alternatives or when to use other commands like stop_container first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dockerbro MCP server](https://glama.ai/mcp/servers/ramanailearning-cpu/dockerbro/badges/card.svg)](https://glama.ai/mcp/servers/ramanailearning-cpu/dockerbro)

Score Badge

Copy to your README.md:

[![dockerbro MCP server](https://glama.ai/mcp/servers/ramanailearning-cpu/dockerbro/badges/score.svg)](https://glama.ai/mcp/servers/ramanailearning-cpu/dockerbro)

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/ramanailearning-cpu/dockerbro'

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