VPS Docker MCP (Advanced)

by mordanov

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., docker_ps vs docker_inspect, system_info vs disk_usage). However, diagnose_vps overlaps with several individual system tools, and diagnostic_command is vague, creating some ambiguity.
Naming Consistency4/5
Tools follow snake_case with clear prefixes (docker_, docker_compose_, system_, etc.). Docker tools use verb_noun pattern, but system tools are mostly noun_noun (e.g., system_info, disk_usage). This mix is not fully consistent but still readable.
Tool Count4/5
26 tools is on the higher side but appropriate for the 'Advanced' scope covering Docker, Docker Compose, and VPS diagnostics. The set is well-scoped, though a few tools could be merged (e.g., diagnose_vps and individual checks).
Completeness3/5
The tool surface covers monitoring and basic state changes for Docker and VPS, but lacks container creation/removal, Docker Compose down, and deeper system management. The diagnostic_command is undefined. Notable gaps exist for a truly 'Advanced' server.
Average 3.2/5 across 26 of 26 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. The description only states the action; it does not indicate that the operation is read-only, whether it requires a running or stopped container, what the output format is, or any side effects. The existence of an output schema reduces the burden slightly, but the description itself gives no behavioral hints beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words), which is concise but at the expense of informativeness. It lacks structure, such as separating purpose from details. While brevity is valued, this is under-specification, not effective conciseness. A sentence that covers purpose and parameter context would earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. However, for a single-parameter tool with no annotations, the description is still woefully incomplete. It fails to explain the tool's value proposition, when to use it, or how to provide the parameter. The overall context of sibling tools and parameter count amplifies the need for more detail.
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% for the single required parameter 'container'. The description adds no meaning beyond the schema—no explanation of what value to use (ID, name, pattern), no example, no format. Baseline for 1 parameter with 0% coverage demands significant compensation, but the description provides none.
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 'Inspect a Docker container' clearly identifies the verb ('inspect') and resource ('container'). This distinguishes it from sibling tools like docker_ps (list), docker_logs (logs), or docker_restart (action). However, it does not specify the scope or level of detail returned, leaving some ambiguity about what 'inspect' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With many siblings (e.g., docker_ps, docker_stats, docker_logs), an explicit context or condition (e.g., 'Use when you need detailed configuration of a single container, not logs or stats') is essential but entirely missing.
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?
No annotations are present, so the description bears full responsibility for disclosure. It does not state whether logs are streamed or returned as a snapshot, what happens if the container is not found, or the format of the output. The single sentence omits critical behavioral details that an agent needs to invoke the tool safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (7 words, one sentence), but this brevity comes at the cost of completeness. It omits essential details about parameters, behavior, and usage context. Conciseness should not sacrifice information that an agent needs to use the tool correctly.
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 (2 parameters, output schema exists, no annotations, many siblings), the description is incomplete. It fails to define 'recent', explain the tail parameter, or differentiate from docker_compose_logs. The output schema does not cover behavioral expectations, so the description should fill that gap but does not.
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%, meaning the input schema provides no textual guidance for the two parameters. The description fails to compensate: it does not explain what 'container' expects (e.g., ID, name) or describe the 'tail' parameter (integer, default 100). The agent must infer parameter semantics solely from the field names and types.
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 a clear verb 'show' and identifies the resource as 'logs from a Docker container', which distinguishes it from sibling tools like docker_ps (listing containers) or docker_stats (metrics). However, 'recent logs' is somewhat vague—it doesn't specify the tail behavior (default 100 lines) or that it shows the end of the log.
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 like docker_compose_logs, docker_inspect, or docker_health. There is no mention of prerequisites (e.g., container must be running) or exclusion criteria, leaving the agent to infer usage context without support.
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 provided, the description must bear the full burden of behavioral disclosure. It states 'This changes server state,' which confirms it is a mutation, but provides no details on how the stop is performed (graceful vs. forceful), what signals are sent, whether there are side effects (e.g., detached volumes), or what happens to dependent services. This is insufficient for an AI agent to understand the tool's behavioral impact.
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 very short at two sentences, but the second sentence 'This changes server state' is arguably redundant for a stop command and adds no new information. While brevity is valued, here it crosses into underspecification—missing critical details that would justify the space. It is concise but not well-structured because it lacks logical progression (no parameter info, no usage context).
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 one parameter, no annotations, and an output schema (not shown), the description is inadequate. It does not explain the parameter, does not mention whether the container must be running, does not specify the stop mechanism or timeout behavior. For a simple tool, this might seem sufficient, but the lack of parameter semantics and safety details makes it incomplete for autonomous use.
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 input schema has 0% description coverage, and the description does not explain the single required parameter 'container'. The agent has no way to know if this expects a container name, ID, or partial match. The description adds zero semantic value beyond the schema's bare parameter name.
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 clearly states the verb 'Stop' and the resource 'a Docker container', making the basic purpose unambiguous. However, it does not differentiate from siblings like docker_restart (which also stops then starts) or docker_compose_stop, leaving ambiguity about when to use this specific tool over alternatives.
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 docker_stop versus docker_restart, docker_kill, or docker_compose_down. There is no mention of prerequisites (e.g., container must be running) or scenarios where this tool is appropriate. The description is a bare statement of action without usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'show recent system journal errors,' which is very minimal. It does not clarify what 'errors' entails (e.g., logs from journalctl, severity levels), whether it is read-only, requires root, or what the output format looks like. A mutation or sensitive operation indicator is missing.
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 a single, short sentence, which is concise but lacks structure. It is front-loaded with the verb, but the brevity leaves critical information missing, making it more under-specified than efficiently 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 has an output schema (context signal) and 2 optional parameters, the description should at least explain the scope of 'errors' and what the output represents. The current description is too sparse to allow an agent to confidently invoke the tool, especially without parameter explanations.
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 adds no parameter-specific information. Neither 'hours' nor 'lines' are explained in the description. The agent must infer meaning solely from parameter names ('Hours', 'Lines') and type ('integer'), which is insufficient for correct usage.
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 clearly states the verb ('show') and resource ('recent system journal errors'). It is sufficiently distinct from sibling tools like 'systemd_failed' or 'diagnostic_command', which have different purposes. The lack of specificity about 'errors' (e.g., severity levels) prevents a 5.
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 on when to use this tool versus alternatives like 'systemd_failed' or 'diagnostic_command'. The description implies it is for recent errors but does not explain when this is the best choice or when to use a different system diagnostics tool. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it only says 'Show Docker Compose services.' This lacks information such as whether it requires a Compose file, works in the current directory, shows running vs. all services, or if it has side effects. The description does not add any behavioral context beyond a vague verb.
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 extremely concise at 4 words, with no wasted text. It is front-loaded with the verb. However, it may be under-specified for a tool with many siblings and no annotations, bordering on too brief. A bit more context would improve understandability 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?
Given the tool has an output schema, the return format is likely specified elsewhere. However, with 20+ sibling tools, zero annotations, and no usage guidance, the description should provide more context (e.g., dependencies, scope, typical use). The description is insufficient for an agent to reliably select and invoke this tool.
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 zero parameters, and schema description coverage is 100% (since there is nothing to describe). The description does not need to add parameter meaning, and it appropriately omits parameter details. However, it could note that no parameters are required, which is implicit. Baseline for no parameters is 4, and the description meets it.
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?
The description 'Show Docker Compose services.' provides a verb ('Show') and a resource ('Docker Compose services'), but it is ambiguous whether it lists services in a project or shows their status. It does not distinguish clearly from sibling tool 'docker_compose_config', which likely shows configuration, or 'docker_ps', which shows running containers. The purpose is clear enough but lacks specificity (e.g., 'List status of services in a Docker Compose project').
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 offers no guidance on when to use this tool versus siblings. For example, it does not say to use this for viewing service state vs. 'docker_ps' for container state, or 'docker_compose_logs' for logs. There is no 'when not to use' or context for its applicability.
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?
No annotations are provided, so the description carries the full burden. The description implies a read-only operation via 'show' but does not disclose behavioral traits such as permissions required, impact on the system, or whether the output is a snapshot vs. real-time. The minimal description fails to inform the agent about potential side effects or access requirements.
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 with no wasted words. It is front-loaded with the core purpose. However, it could be improved by integrating the parameter 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?
Given the tool has a simple schema (one parameter, existing output schema) and low complexity, the description should at least mention the parameter or provide nuance about the output. It does not, leaving the agent without guidance on how to use the 'limit' parameter or what to expect in the return (though output schema exists).
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 input schema has one parameter (limit) with 0% description coverage. The description does not mention the 'limit' parameter or its purpose (e.g., controlling the number of returned processes). With low schema coverage, the description should compensate but fails to add any meaning beyond the schema's default value.
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 shows processes consuming the most CPU and memory. It uses a specific verb ('show') and resource ('processes'), and distinctly separates from sibling tools like docker_ps (container processes) and system_info (general system info).
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 system_info or diagnostic_command. The description only states what the tool does, leaving the agent to infer usage context without any exclusions or conditional recommendations.
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 states that restarting changes server state, which is a key behavioral cue. However, no annotations are provided, so this is the only disclosure. It does not mention whether the tool is destructive, if it requires specific permissions, or what happens to running containers.
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 extremely concise at two sentences with no extraneous information. It is front-loaded with the core action and follows with a single behavioral note.
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 that the tool has no annotations, no enum values, and 0% schema coverage, the description is insufficient. An output schema exists but the description doesn't hint at what is returned. More context about prerequisites, side effects, and default behavior is needed.
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 0% (no parameter descriptions), and the description only implies that 'service' is an optional string. It doesn't explain what 'service' means (e.g., service name in compose file, format expectations, or default behavior when empty).
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 clearly states the action ('Restart Docker Compose services') and notes the side effect ('This changes server state'), which distinguishes it from inspection tools like docker_ps or docker_logs. However, it could be more specific about which Docker Compose services are affected (all or a given service).
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 like docker_restart or docker_compose_up. It doesn't mention prerequisites (e.g., compose file presence), when not to use it, or scenarios where other tools would be more appropriate.
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?
No annotations are provided, so the description carries full burden. It correctly states the tool is 'read-only' and runs 'diagnostic commands', implying safe, non-destructive behavior. However, it doesn't disclose potential side effects (e.g., resource usage, error handling, return format), leaving gaps in behavioral expectations.
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-loades the key purpose: 'run one of a small predefined set of read-only diagnostic commands'. Every word adds value, with no filler or redundant phrasing.
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 only 1 parameter (undocumented), an output schema present but unspecified, and many sibling tools, the description is incomplete. It doesn't explain what the output contains, what commands are valid, or how this differs from `diagnose_vps` and other diagnostic tools. A richer description is needed given the tool's complexity.
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 0% (no description in schema), so the description must compensate. It mentions the tool runs a 'small predefined set of diagnostic commands', which implies the single `command` parameter selects from that set. But it doesn't list or hint at valid command values, leaving the agent to guess. Baseline 3 given the minimal information.
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 clearly states the tool runs 'read-only diagnostic commands' from a 'small predefined set'. This distinguishes it from sibling tools like `diagnose_vps` and other docker/system tools by emphasizing read-only diagnostics. However, it doesn't specify what commands are available or mention the single parameter, leaving some ambiguity about scope.
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 `diagnose_vps`, `system_info`, or `docker_health`. It doesn't mention prerequisites, context, or exclusion criteria, which is inadequate given the many sibling tools with overlapping diagnostic purposes.
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 carries the full burden of behavioral disclosure. It does not mention whether the tool requires elevated permissions, whether it modifies state, or any rate limits. The description implies a read-only query but does not confirm safety.
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 covers the key outputs. Every word adds value, and it is front-loaded with the verb 'Show' followed by the resource and specific fields.
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 description covers what the tool returns but lacks guidance on parameter format, usage context, and behavioral details. An output schema exists but is not provided here; if it details the return structure, completeness improves, but the description alone is minimal.
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 0% and there is only one required parameter, 'container'. The description does not explain what the container value should be (name, ID, or regex). However, with a single parameter named 'container', the semantics are somewhat inferable. Baseline is 3 because the schema does not describe the parameter.
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 clearly states the tool shows container state, restart count, and health status. It identifies the output fields, distinguishing it from sibling tools like docker_ps or docker_inspect which show different information.
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. There is no mention of prerequisites, context for health status interpretation, or comparison to siblings like docker_ps (which also shows status) or docker_inspect (which shows detailed health).
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?
With no provided annotations, the description has the full burden of disclosing behavioral aspects such as whether this refreshes the image list from a registry (local only) or network calls. Stating 'List Docker images' implies a safe, read-only operation. While it does not explicitly mention side effects or permissions, its simplicity makes it easy to infer that no state modification occurs, aligning with typical list operations.
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, terse sentence with no fluff or unnecessary details. It front-loads the action ('List') and clearly identifies the target ('Docker images'). While simple, it earns its keep by being immediately scannable, though it sacrifices a bit of detail on scope (e.g., local vs remote images) that might be useful.
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 that this is a list operation with no parameters and a simple purpose, the description is mostly complete for a basic understanding. However, there is no mention of what output is returned (e.g., image tags, sizes, etc.) despite having an output schema. The context of sibling tools like docker_inspect suggests more detailed alternatives exist, but this tool's description does not reference them or clarify its bounded scope.
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 tool has zero parameters, and the schema description coverage is 100% (since there are none to cover). The description does not need to add parameter documentation since there are no parameters to document. The lack of parameters is consistent with the description, but no additional semantic value is added beyond what the schema already implies.
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?
The description 'List Docker images' clearly states the action (list) and the resource (Docker images), which provides a basic understanding of the tool's purpose. However, it does not distinguish itself from sibling tools like docker_ps (which lists containers) or docker_volumes (which lists volumes), missing an opportunity to differentiate based on the resource type. It is functional but lacks the specificity to stand out among many Docker inspection tools.
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?
There is no guidance on when to use this tool versus alternative tools such as docker_ps for containers or docker_inspect for detailed information. The description implies basic listing functionality but does not mention filtering, output format, or contexts where this tool is preferred over more specialized list-like tools. The absence of any usage cues means an AI agent receives no strategic direction.
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 present, the description must fully disclose behavioral traits. It only states 'This changes server state,' which is minimal. It does not describe what happens if the container is already running (error or no-op), whether the call returns immediately or waits for the container to become healthy, permission requirements, or potential side effects. For a mutating tool, this is insufficient.
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 two sentences long with no extraneous words. The first sentence states the purpose, and the second adds a brief behavioral note. It is front-loaded and efficient, earning its place without any filler.
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 (one parameter, well-defined output schema), the description is still incomplete. It lacks usage guidelines, parameter elaboration, and behavioral context beyond a minimal state-change note. The output schema exists but is not shown in the description; the agent cannot infer return values or success indicators from the description alone.
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 0%. The description adds no information about the 'container' parameter beyond what the schema shows (a required string). It does not clarify whether the value should be a container name, ID, or partial match, nor does it specify format constraints. The tool's description adds negligible value for parameter understanding.
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 'Start a Docker container' with a specific verb and resource. The verb 'start' naturally distinguishes this tool from sibling tools like 'docker_stop' (stop), 'docker_restart' (restart), and 'docker_compose_up' (start a compose stack). The purpose is unambiguous and directly actionable.
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. For example, it does not clarify prerequisites (e.g., container must exist, image must be pulled), nor does it mention when to prefer 'docker_compose_up' for multi-container services. The description lacks any context framing for appropriate usage.
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?
No annotations are given, so the description must fully convey behavior. The description says 'Render and validate', but does not disclose what happens on failure, whether it writes to files, or if it only checks syntax versus also checking semantics. This is insufficient for a diagnostic tool.
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 very short (one sentence, five words), which is concise, but it is arguably under-specified. While it has no wasted words, the brevity sacrifices clarity for behavioral and usage aspects. A slightly longer description would be more helpful.
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 parameters and an output schema present, the description only needs to explain what the tool does and the value of its output. However, it does not mention the return type or what 'render' means (e.g., outputs YAML/JSON, shows resolved configuration). The lack of context for a diagnostic tool makes it incomplete.
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?
There are zero parameters and schema coverage is 100%, so the description correctly does not need to add parameter details. The baseline is 4 because no parameters exist to explain.
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 clear verb-resource pair ('Render and validate') specifically tied to 'Docker Compose configuration'. It is distinct from sibling tools like docker_compose_ps or docker_compose_logs, which have different purposes.
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. For instance, there is no mention of when validation is needed, or how it differs from simply running docker_compose_up to check syntax. The tool has no parameters, so usage context from descriptions is even more critical.
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?
No annotations provided, and description only says 'Show Docker disk usage.' Does not disclose side effects, authorization needs, or whether it is a read-only operation. With no annotations, the description carries the full burden and fails to provide behavioral context.
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?
Single sentence, perfectly front-loaded, no wasted words. Achieves maximum conciseness for the required message.
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?
Output schema likely provides return value details, so description need not detail them. However, it lacks context on whether disk usage is summary or per-object, and no mention of cache or build artifacts. Adequate but not rich.
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?
Tool has zero parameters, so baseline is 4. The description does not need to add parameter details beyond what the schema already covers (empty schema).
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?
Description clearly states verb 'Show' and resource 'Docker disk usage,' distinguishing it from system-wide 'disk_usage' sibling. However, it could be more specific about what objects are included (images, containers, volumes, etc.).
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 like 'docker_images' or 'disk_usage.' No prerequisites or exclusions 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 description explicitly states 'This changes server state,' which signals a side effect. However, with no annotations provided, it misses other behaviors like whether it requires root/sudo, possible downtime, or if it preserves container settings. The statement is helpful but incomplete.
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 very short, containing only two sentences. The first sentence is action-oriented and front-loaded. It could be even more concise if the second sentence were omitted, but it adds value by signaling behavioral impact.
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 low schema coverage and no annotations, the description should provide more context about return values (especially since an output schema exists), error cases (e.g., container not running), and usage context. It is minimally acceptable for a simple restart operation but not comprehensive.
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 only parameter 'container' is minimally described in the schema (just a string), and the description adds no extra meaning. Since schema description coverage is 0%, the description does not compensate. Baseline is 3 due to low coverage and lack of additional info.
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 a specific verb and resource ('Restart a Docker container'), which clearly indicates the action. It is distinct from sibling tools like 'docker_stop' and 'docker_start', though it doesn't explicitly differentiate from 'docker_compose_restart', which is for Compose services.
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 like 'docker_stop' followed by 'docker_start', or the Compose variant. There is no mention of prerequisites, conditions for safe restart, or when to avoid using it.
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?
No annotations are present, so the description bears full responsibility for disclosing behavioral traits. It merely states 'List Docker volumes' without mentioning scope (e.g., all volumes vs. used volumes), side effects (none expected), or any prerequisites. This is a critical gap.
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 with no wasted words. However, it could be slightly more informative (e.g., noting that it lists all volumes) without sacrificing conciseness. Still, it is very efficient.
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 tool has no parameters and an output schema exists (reducing the need to describe return values), the description is minimally complete. However, it lacks behavioral context and does not clarify what 'volumes' means (e.g., named volumes only, or all volumes). This is adequate but not thorough.
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, and schema description coverage is trivially 100%. With no parameters, the description adds no further meaning, but the baseline score of 4 is appropriate because the schema already fully documents the input. The description is adequate.
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 "List Docker volumes." uses a specific verb ('List') and resource ('Docker volumes'), clearly distinguishing it from sibling tools like docker_ps, docker_images, and docker_networks which list other Docker resources.
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. With many sibling Docker listing tools, the description should at least imply when to choose volumes over containers or images, but it does not.
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 implies a non-destructive read operation ('Show'), but with no annotations present, the burden is on the description to disclose behavioral traits. It does not mention pagination, truncation, rate limits, or authentication requirements. The output schema exists but the description doesn't reference 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?
The description is a single sentence of 10 words, front-loaded with the core action. It contains no filler or redundant information, earning 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?
Given the tool has 2 parameters, 0% schema coverage, no annotations, and an output schema, the description is too brief. It does not clarify that logs come from a Docker Compose project, that tail defaults to 100 lines, or what the output format is. The agent lacks sufficient context to use the tool correctly.
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?
With 0% schema description coverage, the description must compensate. It adds meaning for the 'service' parameter (optional, filters to one service) but provides no information about the 'tail' parameter (number of lines). This is insufficient for both parameters.
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 'Show Docker Compose logs, optionally for one service' clearly states the verb (Show), resource (Docker Compose logs), and optional filtering by service. This distinguishes it from sibling tools like docker_logs (individual container logs) and docker_compose_ps (status).
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_logs or docker_compose_ps. There is no mention of when not to use it or which scenarios it is best suited for.
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?
No annotations are provided, so the description alone must convey behavioral traits. It only states the function without disclosing whether the operation is safe, requires elevated privileges, or covers all mount points. This is insufficient for a tool that could be used in sensitive or automated contexts.
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 immediately conveys the tool's purpose. It is front-loaded and contains no extraneous words, though it could be slightly more informative without sacrificing brevity.
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 inputs and an existing output schema, the description is minimally adequate. However, it omits context such as whether it reports on all filesystems or just the root, and does not hint at the output format. Given the tool's role in diagnostics, slightly more detail would improve completeness.
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?
There are no parameters, so the schema fully describes the input. The baseline for 0 parameters is 4, and the description adds no additional parameter semantics, which is appropriate given the absence of parameters.
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 'show' and clearly identifies the resource as 'filesystem space and inode usage.' This effectively distinguishes it from sibling tools like docker_disk_usage (Docker-specific) and system_info (broader system information).
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 when not to use it, nor does it reference sibling tools like top_processes or network_info that might be more appropriate for different diagnostic tasks.
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 states 'This changes local Docker image state', which is a behavioral note beyond the tool name. With no annotations provided, this adds minimal context about side effects. It does not disclose other behavioral traits such as idempotency, network requirements, or potential disk usage increase.
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 consists of two short sentences with no redundant or filler content. Every word serves a purpose.
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 no parameters and an output schema (not shown), the description is somewhat complete for a simple action. However, it does not explain return values or behavior when no docker-compose file is present, nor does it differentiate from siblings. The tool is part of a large suite, and more context would help agent selection.
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?
There are zero parameters, so the baseline is 4. The description correctly does not add parameter info since none exist. The input schema already fully covers the structure.
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 clearly states 'Pull Docker Compose images', specifying the verb 'pull' and resource 'Docker Compose images'. This distinguishes it from sibling tools like docker_compose_up (which runs containers) and docker_images (which lists images). However, it does not clarify scope (all services or specific).
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 given on when to use this tool versus alternatives like docker_compose_up or docker pull. The description does not mention prerequisites (e.g., requiring a docker-compose file) or conditions under which pulling is appropriate.
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 provided, the description must disclose behavioral traits, but it only states 'List Docker networks'. It does not reveal whether all networks are listed, if any filtering applies, or what the output contains. The existence of an output schema is not leveraged to add context.
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 of three words, which is concise and front-loaded. However, it lacks any structure or additional sentences that could provide context without being verbose. It earns its place for simplicity but could be slightly more informative.
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 tool's simplicity (zero parameters, a list operation), the description is minimally adequate. The existence of an output schema covers return values, but the description does not clarify the scope (e.g., 'all networks on the host') or any behavioral details. It is complete enough for a basic list but lacks contextual richness.
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?
There are zero parameters, and schema coverage is 100% (trivially). The description adds no extra meaning beyond the schema, but for a parameterless tool, the baseline of 4 is appropriate. No information is missing regarding parameters.
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 'List Docker networks' uses a specific verb ('List') and resource ('Docker networks'), clearly stating its function. It unambiguously distinguishes itself from sibling tools like docker_ps (lists containers) and docker_images (lists images).
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 vs alternatives. It does not mention any prerequisites, exclusions, or context such as 'for detailed network info use docker_inspect' or 'use this to see all networks on the host'. The agent must infer usage entirely 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?
With no annotations, the description carries the full burden. It correctly indicates a read-only operation ('Show') but does not disclose whether elevated privileges are needed, whether the output is real-time or cached, or the format of the output. The absence of anomalies is acceptable, but more detail would benefit an agent.
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, well-structured sentence that front-loads the action and lists the key resources. No filler or repetition.
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 tool has no parameters and a moderate number of sibling tools, the description is minimally sufficient. However, it does not mention the output schema or what an agent should expect in return, which would strengthen completeness.
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 zero parameters with 100% coverage, so the description trivially covers all parameters (none). The baseline is 4 for zero-parameter tools, and the description adds no confusion.
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 clearly states the verb 'Show' and the resources: 'network interfaces, routes and listening TCP/UDP ports.' It is specific enough to distinguish from sibling tools like 'system_info' or 'disk_usage', though it could be more precise about the scope (e.g., all vs. specific interfaces).
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 on when to use this tool versus alternatives like 'diagnose_vps' or 'system_info'. The description implies diagnostic use but does not state prerequisites, scope limitations, or exclusion criteria.
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?
With no annotations provided, the description carries the full burden. It states the action is 'Show', implying a read-only operation. However, it does not disclose what output format to expect, whether it requires elevated privileges, or if it affects system state. Given no annotations, a score of 3 indicates it provides basic transparency but lacks depth.
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 and efficient, earning its place.
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 tool has zero parameters and an output schema exists, the description could be more complete by hinting at what the output contains (e.g., service names, statuses). The output schema reduces the need to describe return values, but the description still feels brief.
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 schema has 0 parameters and schema description coverage is 100%, so the description does not need to add param info. Baseline is 4, and the description is clear about what the tool does with no parameters.
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 clearly states the tool's purpose with a specific verb ('Show') and resource ('failed systemd services'). It distinguishes itself from sibling tools like 'system_info' and 'diagnose_vps' by focusing narrowly on systemd failures.
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 checking failed systemd services but provides no guidance on when to use this vs. alternatives like 'journal_errors' or 'diagnostic_command'. There are no exclusions, prerequisites, or context about when this tool is appropriate.
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?
With no annotations provided, the description bears the full burden of behavioral disclosure. 'List' implies a read-only operation, and the flag behavior is clearly stated, which is adequate for a simple tool, but it does not disclose return format or any additional effects.
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 primary purpose and parameter behavior with no extraneous 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 tool with one optional parameter and an output schema, the description covers the functionality sufficiently. It explains the only parameter's effect and the tool's core purpose, though it omits any context about when to use it vs compose tools.
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 provides only a type and default, with no description, so the description's explanation of 'all_containers' adds essential meaning by clarifying that setting it to true includes stopped containers.
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 clearly identifies the action ('List') and resource ('Docker containers'), and the mention of 'include stopped containers' clarifies its scope. It is distinguishable from sibling tools like docker_images, though it does not explicitly contrast with docker_compose_ps.
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?
No explicit guidance on when to use this tool versus alternatives is provided. However, the purpose is self-evident for listing containers, so usage is implied rather than clearly established.
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?
No annotations are present, so the description carries the full burden. It accurately states what information is shown, but does not disclose any behavioral traits such as the output format, real-time nature, permission requirements, or side effects. For a simple read-only tool this is minimally adequate, but lacks depth.
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 of 12 words that is front-loaded and to the point. Every word contributes to the purpose. No redundancy or unnecessary detail.
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 tool has no parameters and an output schema exists, the description covers the basic purpose. However, it does not mention the output format or differentiate from sibling diagnostic tools like diagnose_vps. For a simple tool this is adequate, but not fully complete.
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?
There are zero parameters, and the schema coverage is 100% (trivially). The description confirms that no inputs are needed, adding meaning beyond the empty schema. It communicates what the tool will return, fulfilling the baseline for a parameterless tool.
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 'Show' and identifies the resource as 'VPS system info', listing the exact categories (uptime, OS, CPU, memory, swap, load, kernel). This clearly distinguishes it from sibling tools like docker_ps or network_info, which target different subsystems.
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. The description does not mention exclusions, prerequisites, or suggest when another tool (e.g., diagnose_vps, top_processes) would be more appropriate. The agent must infer usage from context alone.
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?
No annotations are provided, so the description must carry the full burden. It discloses that the tool 'changes server state,' implying destructive or mutation behavior, but it does not detail what actually happens (e.g., builds images, recreates containers, or just updates settings). It also does not mention whether it requires Docker Compose files to be present in a specific directory or if it could fail silently.
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 just two sentences and each sentence provides distinct value—the purpose and a behavioral trait. However, the second sentence ('This changes server state.') is somewhat redundant with the first and could be omitted or merged without loss of meaning.
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 tool has no parameters and an output schema is present, the description does not need to explain return values. However, it does not clarify key failure scenarios (e.g., missing docker-compose.yml), prerequisites (Docker installed, file present), or what 'update' means in terms of state changes. For a tool that modifies server state, this is incomplete.
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 0 parameters and 100% schema description coverage, so there is nothing to document. The description does not add any parameter details because none exist. With no parameters, the baseline is 4, and the description does not detract from this.
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 ('Start/update') and resource ('Docker Compose stack') with a clear behavioral modifier ('detached mode'). It clearly distinguishes itself from siblings like docker_compose_restart and docker_compose_ps.
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 says this 'changes server state,' implying it's a mutation tool, but it does not explicitly state when to use this tool versus alternatives like docker_start, docker_restart, or docker_compose_restart. No when-not-to-use guidance is provided.
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?
No annotations are provided, so the description must carry behavioral disclosure. It correctly implies a read-only operation ("Show") with no destructive side effects. However, it doesn't mention if all containers are shown or only running ones, or the output format/structure. The description is adequate but lacks depth.
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, short sentence that captures the exact purpose. No filler or redundancy. 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?
With zero parameters, an output schema present, and 100% schema coverage, the description need only clarify the purpose and scope. It does so effectively. Minor miss: no mention of whether this targets running containers or all containers, but given the tool's simplicity, this is a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and schema description coverage is 100%. The description adds no parameter info because none exists. This is a fully documented case with no gaps—no compensation needed.
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 clearly states the verb "Show" and the resource "containers" with specific metrics (CPU, memory, network, block I/O). It distinguishes from siblings like docker_ps (listing) or docker_logs (logs) by focusing on usage metrics. Could be more specific about scope (running containers only?) but is clear overall.
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 this is for monitoring container resource usage, which is distinct from listing containers (docker_ps) or inspecting details (docker_inspect). However, no explicit when-to-use or when-not-to-use guidance is given, nor mention of prerequisites like needing a running container.
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?
With no annotations provided, the description carries full burden for behavioral transparency. It says 'compact' (implying non-destructive, quick), but does not specify if it runs multiple commands, requires elevated privileges, or has side effects on the system. For a diagnostic tool with many sibling alternatives, more disclosure would be helpful.
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 efficiently conveys the purpose and scope. Every word serves a purpose; no filler.
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 no parameters, a comprehensive output schema, and many sibling tools, the description adequately describes the tool's purpose. It could be enhanced by hinting at what the output looks like (e.g., 'returns a summary table'), but is largely sufficient for an AI agent to select and invoke this tool over its siblings.
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 (0 params), so the baseline is 4. The description does not add param info, but none is needed. It clearly states the scope of the check.
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 ('Run') and resource ('VPS health check') and lists the specific areas covered: resources, disk, systemd, and Docker. This effectively distinguishes it from the many sibling tools that focus on individual aspects like Docker commands, system_info, disk_usage, or systemd_failed.
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 this is for a quick health overview of a VPS, but it does not explicitly state when to use this tool versus the many sibling tools (e.g., when would you prefer this over system_info or diagnostic_command). There is no guidance on prerequisites or when not to use it.
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:

[![vps_mcp MCP server](https://glama.ai/mcp/servers/mordanov/vps_mcp/badges/card.svg)](https://glama.ai/mcp/servers/mordanov/vps_mcp)

Score Badge

Copy to your README.md:

[![vps_mcp MCP server](https://glama.ai/mcp/servers/mordanov/vps_mcp/badges/score.svg)](https://glama.ai/mcp/servers/mordanov/vps_mcp)

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/mordanov/vps_mcp'

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