infra-mcp

by DTG404

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes: system monitoring tools target different metrics, and Docker tools separate list/inspect/logs/start/stop/restart. Minor overlap exists between list_containers and compose_status (both list containers but with different grouping) and between container_health and inspect_container (health info is a subset of inspect), but descriptions help differentiate them.
Naming Consistency3/5
The naming is mixed: system and GPU tools use noun_noun patterns (system_overview, gpu_status, disk_usage), while Docker tools use verb_noun patterns (list_containers, start_container, restart_container). This inconsistency is mildly confusing, though the pattern is predictable within each subdomain, and all names are readable.
Tool Count4/5
21 tools is on the higher end of the optimal range, but each tool covers a specific monitoring or Docker management function that justifies its presence. The count is appropriate for a server that spans both system health and container operations, without feeling bloated.
Completeness3/5
The server covers system monitoring and Docker container lifecycle well, but has notable gaps: no service management (only status), no Docker container create/remove, no image pull/remove, and no volume/network creation. Basic operations are covered, but full infrastructure management is incomplete.
Average 3.4/5 across 21 of 21 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It does not mention return format (text or JSON), potential errors, permissions needed, or whether the operation is read-only. It simply restates the tool's function without adding any contextual behavior.
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 with zero waste. It efficiently communicates the core purpose without any superfluous words or repetition.
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 absence of annotations and an output schema, the description falls short of providing a complete picture. It does not explain what 'full inspect details' entails, how the result is structured, or when to use this tool relative to siblings. For a simple tool, some of this context is necessary for safe and correct invocation.
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 has 100% coverage, with clear descriptions for both 'id' (Container ID or name) and 'format' (Output format with enum). The description does not add extra semantic value beyond the schema, so the baseline of 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 states a clear action ('inspect') and resource ('Docker container'), and the word 'Full' implies comprehensive details. While it doesn't explicitly differentiate from sibling tools, the verb 'inspect' is unique among them, making the purpose apparent.
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 gives no guidance on when to use this tool versus alternatives like list_containers or container_logs, and it does not mention any prerequisites or exclusions. Only the bare purpose is stated.
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. It only says 'Show' which implies a read, but does not disclose output details, whether it lists all containers or requires an ID, or any edge cases. The behavior is under-specified.
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 front-loads the main purpose and avoids 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?
Despite being a simple tool with one optional parameter and no output schema, the description is under-specified. It does not explain return format, scope, or how it relates to other Docker health-related commands, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional 'format' parameter, which has an enum and a description. The description adds nothing beyond the schema, so the baseline of 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 a clear verb 'Show' and names a specific resource: 'Docker container health check status'. This distinguishes it from sibling tools like list_containers and inspect_container, which address different aspects. However, it lacks scope detail (e.g., all containers or a specific one), which 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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, contexts, or exclusions, and no reference to similar tools like container_logs or docker_stats.
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 disclose safety and behavioral traits. It only says 'show or perform' without explaining that pruning is destructive and irreversible, nor that dry_run defaults to true. This is a significant transparency gap for a potentially data-deleting 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, short sentence without wasted words. However, the brevity creates ambiguity (e.g., 'summaries'), which could have been clarified in the same length. Still, it is appropriately 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?
The tool has no output schema or annotations, and the description doesn't explain the return format, the safety mechanism (dry_run), or the conditions under which actual deletion occurs. For a pruning tool that can remove data, this is incomplete guidance.
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 documents both parameters (format and dry_run) with descriptions and defaults. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline 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 clearly identifies the tool as dealing with Docker system prune operations and indicates two modes ('show or perform'). It distinguishes from sibling tools like disk_usage or list_containers by focusing on pruning, though 'summaries' is a bit vague.
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 alternatives, nor any conditions under which pruning is appropriate. No exclusions or alternative tools are mentioned, so the agent receives no contextual 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?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action without explaining side effects (e.g., stopping then starting), required permissions, reversibility, or how the operation affects the container's configuration/state. This is a significant gap for a mutating tool.
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 redundant text or structural issues. It is front-loaded and efficient, though it could be slightly expanded to include behavioral 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?
Despite having a simple schema, there is no output schema or annotations, and the description does not mention return values, whether it waits for the container to be healthy, or any other post-restart behavior. Given the tool's mutating nature, this level of detail is insufficient for an agent to understand the full scope of the 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?
The input schema provides complete descriptions for both parameters (id and format), covering 100% of parameters. The description itself does not add any parameter-level meaning beyond the schema, so the baseline score of 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 states the specific action 'Restart' applied to 'a Docker container', which is clear and distinct from sibling tools like start_container and stop_container. However, it does not explicitly differentiate itself from those siblings, though the verb 'restart' implicitly covers stop+start.
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 the alternatives such as start_container or stop_container. The description does not provide context for choosing restart over stop/start, nor does it mention any preconditions or scenarios where restart 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 carries the full burden of behavioral disclosure. It only states 'tail logs' without explaining whether it streams continuously, returns only the tail count, requires the container to be running, or how the 'since' parameter affects results. The agent is left to infer these behaviors from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, directly stating the tool's purpose. It is front-loaded and appropriately sized for its simplicity.
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 no output schema and no annotations, leaving the description as the primary source of context. The one-line description is insufficient for an agent to understand the return format, edge cases, or when to apply this tool relative to sibling tools. The schema covers parameters but does not compensate for the lack of high-level context.
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 descriptions cover 100% of the parameters (id, tail, since, format), so the baseline of 3 is appropriate. The description adds no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tail logs from a Docker container' clearly identifies the tool's function (retrieving logs) and resource (Docker container), distinguishing it from sibling tools like start_container or docker_stats which have different purposes. 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 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 lacks any mention of scenarios, prerequisites, or exclusions, such as when to use docker_stats instead for resource monitoring.
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 that only running containers are listed by default (unless 'all' is true), nor does it explain output format, side effects, or any limitations. This lack of detail leaves the agent uncertain about the tool's behavior.
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 concise single sentence that communicates the core purpose without redundancy. It is front-loaded with the verb and resource, making it easily scannable.
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 and rich parameter schema, the description is adequate but not thorough. There is no output schema, and the description does not clarify what fields are returned (e.g., IDs, names, statuses) or the default behavior regarding stopped containers, leaving minor gaps for a list 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?
The input schema already documents all four parameters with descriptions, achieving 100% schema description coverage. The tool description adds no additional parameter information, so it meets the baseline without adding extra 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 lists Docker containers, using the specific verb 'List' with resource 'Docker containers'. It distinguishes itself from sibling tools like inspect_container (which focuses on a single container) and container_logs (which retrieves logs).
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 phrase 'with optional filters' hints at filtering capabilities but does not state appropriate contexts, exclusions, or relationships to sibling tools like compose_status or list_images.
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 mentions 'optional timeout' but does not explain that the timeout is the wait before force-killing, nor does it disclose the container state change or potential side effects beyond stopping.
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 with no redundant words. Every word contributes to conveying the tool's core purpose and distinguishing feature.
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?
As a simple tool with all parameters documented in the schema, the description provides the essential purpose. However, without annotations or output schema, it lacks information about return values, behavior when container is already stopped, and the kill-after-timeout detail. It is minimally viable 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?
Schema covers all three parameters (id, format, timeout) with descriptions. The description adds only that timeout is optional, which is already implied by the schema default. Baseline of 3 is appropriate given high schema coverage.
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 'Stop a running Docker container with optional timeout' clearly identifies the verb (stop), resource (Docker container), and the optional timeout parameter. It distinguishes well from sibling tools like start_container and restart_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?
No explicit guidance is provided on when to use this tool versus alternatives (start/restart), nor are prerequisites or conditions for use mentioned. The usage context is only implicit in the verb 'stop'.
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 behavioral burden. It adds the useful trait 'one-shot' and limits scope to 'running containers', but it does not disclose side effects (likely none), error conditions, or what the output contains. It 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, front-loaded sentence with no wasted words. It communicates the essential purpose and scope immediately.
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 (one optional parameter, no output schema, no annotations), the description is mostly sufficient. However, it does not detail what statistics are returned, how output varies between text and JSON, or how errors are handled, leaving minor gaps for an agent relying solely on this text.
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 sole parameter 'format' is fully described in the input schema with enum values and a default. The description adds no additional meaning, so the baseline 3 applies given 100% schema coverage.
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 ('show') and resource ('Docker stats') with clear scope ('running containers') and a key qualifier ('one-shot') that distinguishes it from long-running stats commands. It is distinct from sibling tools like list_containers or top_processes, though it does not explicitly name alternatives.
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 when you need a snapshot of container resource usage, but it does not explicitly state when to use it versus alternatives or mention any prerequisites or exclusions. No guidance is provided beyond the core purpose.
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 carry the full burden of behavioral disclosure. It mentions that it 'shows' stress but does not state that it is a read-only operation, what system files it reads, or what the output format will be. This is minimal transparency beyond the obvious.
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 tool's purpose without wordiness or irrelevant 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's simplicity (one optional parameter, no output schema), the description is adequate but has gaps: it does not explain the nature of the returned data (e.g., PSI values like avg10, avg60, avg300) or how 'format' affects output. An agent would know the purpose but not the exact output structure.
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% (the only parameter 'format' is fully described), so baseline is 3. The tool description does not add any extra meaning about the format parameter or its values beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing PSI (Pressure Stall Information) for CPU, memory, and I/O, and states its purpose: to show if the system is under real stress. This is a specific verb+resource+scope and distinguishes it from sibling tools like system_overview or top_processes.
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 system stress but provides no explicit guidance on when to use this tool versus alternatives such as memory_detail or top_processes. It lacks any exclusions or comparison to sibling tools.
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. It adds 'warnings' as an output element, but does not disclose whether the operation is read-only, what permissions are needed, or any other behavioral traits. The name 'list' implies non-destructive, but this is not explicit in the description.
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. It avoids unnecessary words and is directly to the point.
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 list tool, this description is minimally viable. It does not explicitly state read-only behavior or what 'warnings' means, but the schema documents the format parameter. Given the low complexity, the description is adequate but leaves some gaps.
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 provides 100% coverage for the only parameter 'format', including an enum and default value. The description adds no additional semantic detail beyond the schema, so the baseline of 3 applies.
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' with a clear resource 'Docker volumes' and an additional 'warnings' output. It distinguishes itself from sibling tools like list_containers, list_images, and list_networks by naming the exact resource.
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 usage is implied from the purpose: use this tool to list Docker volumes. However, there is no explicit guidance on when to prefer this over alternatives or any exclusions. The description does not mention when not to use it or how it differs from other list commands.
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 states the basic action ('Check systemd service status') but does not mention that this is a read-only operation, that it may require elevated privileges for system services, or what the output contains beyond 'status'. It also fails to describe the impact of the 'format' parameter on output. This lack of transparency means the agent lacks safety and context 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, concise sentence that front-loads the core action and scope. There is no wasted text, and every word contributes to understanding the tool's purpose. It is appropriately sized for a simple tool with a clear function.
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 has three parameters and no output schema, so the description should provide context about expected return values or error behavior. The description only states 'Check systemd service status' without explaining what status information is returned or whether output can be formatted as JSON (despite the 'format' parameter). This is a gap, but the tool is relatively simple and the schema covers parameter semantics, so the description is adequate 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 input schema provides full descriptions for all three parameters: service (with an example), user (explains --user flag), and format (enum listing text/json). The description adds no additional parameter-level meaning, but since the schema coverage is 100%, the baseline of 3 is appropriate. The description's mention of 'system or user unit' aligns with the 'user' parameter but does not enrich beyond schema documentation.
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: 'Check systemd service status (system or user unit)'. It specifies a concrete verb ('Check') and resource ('systemd service status'), and the parenthetical clarifies scope (system or user units). This distinguishes it from sibling tools like system_overview or gpu_status, which target different system aspects.
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 implicitly indicates when to use the tool—whenever a systemd service status is needed—but it does not explicitly mention alternatives or exclusion criteria. No guidance is provided about when to prefer another tool (e.g., system_overview for broader system health) or when not to use this tool. The usage context is inferable from the name and description but not directly stated.
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 states the action and precondition, but does not disclose side effects, error conditions (e.g., container not found or already running), required permissions, or output behavior. This is a significant gap for a mutating operation.
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 with no unnecessary words. It conveys the essential purpose efficiently, earning its place without filler.
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 a complete schema and no output schema, the description covers the core function but lacks detail on edge cases and return behavior. Given the context of sibling tools, a bit more guidance could improve completeness, but the description is minimally viable.
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 provides descriptions for both parameters (id: 'Container ID or name', format: 'Output format' with enum and default). With 100% schema coverage, the description adds no additional parameter meaning, so the baseline of 3 applies.
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 Docker container' clearly states the specific action (start), the resource (Docker container), and the precondition (stopped). This differentiates it from siblings like restart_container and stop_container, making the tool's function 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?
The description implies usage for starting stopped containers but provides no explicit guidance on when not to use it or alternatives. There is no mention of restart_container for restart scenarios or behavior when the container is already running, so guidance is only implied.
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 full burden for behavioral disclosure. It only states the core function and doesn't mention that this is a read-only operation, what the output contains, or any side effects. This is a minimal description with no added 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?
The description is a single, concise sentence with no unnecessary words or repetition. It is front-loaded with the essential information.
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, and the schema covers all parameters, but there is no output schema and no annotations. The description doesn't indicate what fields are returned (e.g., PID, command, CPU%), which would be useful. It is minimally complete but could benefit from a brief note on return format.
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?
All parameters are fully documented in the schema (100% coverage), so the description doesn't need to add much. It does mention CPU or memory usage, which aligns with sort_by, but nothing beyond what the schema already explains. Baseline 3 applies.
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 returns the top N processes sorted by CPU or memory usage, identifying both the resource (processes) and the scope (N, sort criteria). This is specific and distinguishes it from sibling tools like gpu_processes or memory_detail.
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 intended use is implied by the name and description—monitoring top processes—but there is no explicit when-to-use guidance or mention of alternatives. The tool is a simple process monitor, but the description doesn't differentiate it from other system overview tools.
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. 'Show' implies a read-only operation with no side effects, which is transparent and aligns with typical status tools. However, it does not disclose potential details like whether stopped containers are included or what happens when no Compose projects exist, leaving some behavioral ambiguity.
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, well-structured sentence that communicates the core function and grouping behavior without any wasted words. It is appropriately sized for the tool's simplicity.
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 status tool with one optional parameter, the description sufficiently conveys the output shape (projects with their containers). Since there is no output schema, the phrasing 'grouped by project' gives the agent a clear expectation of the return structure, making it complete enough for the context.
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 already covers 100% of the only parameter, 'format', with an enum and description. The tool description adds no additional context or syntax guidance beyond what the schema provides, so the baseline of 3 applies.
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: Docker Compose projects with their containers. It adds the distinguishing detail 'grouped by project', which differentiates it from sibling tools like list_containers that do not group by 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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it reference sibling tools such as list_containers or docker_stats that might be better suited for non-Compose 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?
With no annotations, the description carries the transparency burden. The verb 'List' implies a read-only operation, but there is no explicit statement about side effects, permissions needed, or output format. The description is adequate but not richly transparent.
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 with no wasted words. It immediately states the resource and what information is included.
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 operation with a single optional parameter, the description is mostly complete. It conveys the main value (IPAM info) and purpose. However, with no output schema, a bit more detail about the exact return fields could elevate it further.
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, 'format', is fully described in the input schema with an enum and default. The description adds no additional meaning beyond what the schema provides, so the baseline of 3 applies.
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'), a clear resource ('Docker networks'), and adds detail ('with IPAM info'). This clearly distinguishes it from sibling tools like list_containers or list_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 given on when to use this tool versus alternatives such as docker_stats or system_overview. The intended use is implied but not explicitly stated, and no exclusions or alternative tool references are 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 carries the full burden. It indicates the data source (/proc/meminfo) and mentions human-readable output, which implies a read-only, non-destructive operation. However, it does not explicitly state side effects, permissions, or error conditions, leaving some gaps for a system tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no redundant words. 'Full /proc/meminfo breakdown with human-readable sizes' efficiently conveys the tool's scope and output style.
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 tool with one optional parameter and no output schema, the description is adequate: it explains what the tool returns (a memory info breakdown) and the output format (human-readable). It does not enumerate specific fields or mention that format can be text or JSON, but those are minor omissions for a simple read tool.
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 fully documents the only parameter 'format' with an enum and description, achieving 100% schema coverage. The description adds no additional parameter meaning, so it does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a full breakdown of /proc/meminfo with human-readable sizes, which is a specific resource and output style. It distinguishes itself from sibling tools like gpu_status or disk_usage by focusing exclusively on memory 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?
There is no explicit guidance on when to use this tool versus alternatives. The description implies it is for memory details, but does not mention when to avoid it, nor does it reference sibling tools or provide selection 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?
With no annotations, the description carries the full burden of behavioral disclosure. It lists what data is returned but does not state that the operation is read-only, mention any authentication requirements, or describe the output format beyond the listed metrics. This is a significant gap for a system health check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core purpose and includes no filler. Every word contributes to understanding the tool's scope.
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 no output schema, the description covers the essential return values (CPU, memory, swap, uptime). It does not mention the 'format' parameter, but that is fully documented in the schema. The absence of annotations is partially mitigated by the inherently read-only nature of a health check.
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 already provides full coverage for the only parameter 'format' with a description and enum. The tool description adds no additional meaning beyond what the schema states, so the 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 tool's purpose with a specific verb 'health check' and lists concrete resources: CPU load averages, memory usage, swap, and uptime. This distinguishes it from sibling tools like gpu_status, disk_usage, and memory_detail.
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 phrase 'One-shot system health check' implies a quick overview use case, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool mentions are provided, leaving usage guidance implied rather than explicit.
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 transparency burden. 'List' implies a read-only operation, but the description does not mention prerequisites like NVIDIA drivers, the output format details, or failure conditions. 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, front-loaded sentence that directly states the action and target. Every word contributes meaning with no redundancy.
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 one optional parameter, but no output schema exists. The description does not hint at the structure of the returned list (e.g., process IDs, memory usage) or error scenarios, leaving a minor completeness gap.
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 documents the single 'format' parameter with enum values and a default, giving it 100% schema coverage. The description adds no extra meaning about the parameter, so the 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?
Description uses a specific verb 'List' and a precise resource 'processes currently using NVIDIA GPU VRAM', making it clear what the tool does. It also distinguishes itself from sibling tools like gpu_status, which likely reports overall GPU health rather than per-process VRAM usage.
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 context is only implied by the description ('List processes...') with no explicit guidance on when to choose this tool over alternatives such as gpu_status or top_processes. There are no exclusion criteria or references to sibling tools.
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 must carry the full burden of behavioral disclosure. It implies this is a read-only status check, but it does not mention potential requirements such as NVIDIA drivers or what happens if no GPU is available. It also does not describe the output format beyond the listed fields. For a simple status tool, this 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?
The description is a single, concise sentence that front-loads the key information: it states the resource (NVIDIA GPU) and immediately lists the most important output fields (name, temperature, utilization, VRAM usage). There is no redundant or filler wording, making it appropriately sized and immediately 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?
Since there is no output schema, the description should clarify the return structure. It lists the fields but does not specify whether the result is a single GPU, a list of GPUs, or how the text/json format affects the output. For a simple status tool, this is adequate but leaves some ambiguity about the exact response format.
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, 'format', is fully described in the schema with an enum (text/json), a default value, and a clear description 'Output format', giving 100% schema coverage. The tool description does not add any extra parametric context, but since the schema fully explains the parameter, the baseline of 3 applies.
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 identifies the tool as retrieving NVIDIA GPU status and lists specific metrics such as name, temperature, utilization, and VRAM usage. This makes it easy to distinguish from sibling tools like gpu_processes, which focuses on processes, and system_overview, which is broader. Although the description is a noun phrase rather than an explicit verb, the tool name 'gpu_status' implies a status retrieval action.
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 the tool is for checking GPU status, which is a reasonable inference, but it does not provide explicit guidance on when to use it over alternatives. There is no mention of related tools like gpu_processes for per-process GPU activity or when not to use this tool. The usage context is implied rather than stated.
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 must fully disclose behavior. It does mention the exclusion of certain filesystem types, which is useful. However, it does not mention read-only nature, output structure, or potential side effects. The provided transparency is minimal but not absent.
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 delivers the core purpose and key exclusions without any fluff. Every word contributes to understanding.
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 no output schema, the description is nearly complete. It explains what the tool does and important exclusions. It could add more about return fields, but given the schema and simplicity, the description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter 'format' is fully described in the schema with enum and default. The tool description adds no extra parameter semantics, so it relies on the schema. 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 states the tool's specific function: reporting disk usage per mount point. It distinguishes itself from sibling tools (e.g., gpu_status, memory_detail) by clearly focusing on disk usage, and the exclusion of tmpfs/devtmpfs/efivarfs adds further specificity.
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 when to use the tool (when disk usage per mount point is needed) but does not explicitly state alternatives or exclusions. No guidance is given on when not to use it or which sibling tool might be preferable for related 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?
With no annotations, the description must carry the behavioral disclosure burden. 'List Docker images' implies a read-only operation and the 'optional all filter' hints at filtering behavior, but it adds no extra context beyond the schema (e.g., default behavior, permission requirements, or return format). It is not misleading but is minimally transparent.
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 with zero wasted words. It communicates the core action and an optional filter efficiently.
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 two optional parameters and no output schema, the description is largely adequate. It clearly names the resource and the key option, though it could mention the configurable output format or the default behavior of the 'all' filter. Overall, it is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description only mentions the 'all' filter but does not enrich parameter understanding beyond what the schema already states. The 'format' parameter is entirely omitted from the description, though it is fully documented in 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 uses the specific verb 'List' with the resource 'Docker images' and mentions an optional filter ('all'), clearly distinguishing it from sibling tools like list_containers or list_volumes. It unambiguously states 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing Docker images but provides no explicit guidance on when to choose this over alternatives or any exclusions. It does not mention when to use the 'all' filter beyond the schema, nor does it reference sibling tools.
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:

[![infra-mcp MCP server](https://glama.ai/mcp/servers/DTG404/infra-mcp/badges/card.svg)](https://glama.ai/mcp/servers/DTG404/infra-mcp)

Score Badge

Copy to your README.md:

[![infra-mcp MCP server](https://glama.ai/mcp/servers/DTG404/infra-mcp/badges/score.svg)](https://glama.ai/mcp/servers/DTG404/infra-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/DTG404/infra-mcp'

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