Enterprise Infrastructure & Metrics MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_LOG_ROOT_DIR | No | Sandbox root directory for analyze_local_logs. Enforced path traversal protection. | /var/log |
| MCP_MAX_LOG_LINES | No | Hard ceiling on lines returned for log tails. | 1000 |
| MCP_TOOL_RETRY_ATTEMPTS | No | Number of retry attempts for transient failures (e.g., Docker daemon calls). | 3 |
| MCP_DOCKER_TIMEOUT_SECONDS | No | Timeout in seconds for Docker daemon socket operations. | 10 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_system_metricsA | Fetch a live snapshot of host CPU (aggregate + per-core), memory (RAM + swap), and disk (usage + I/O counters) metrics. Use |
| manage_docker_containersA | Read-only Docker introspection: list containers, inspect a specific container's health/state, or fetch the tail of a container's logs. Does NOT start, stop, restart, or remove containers -- this tool cannot mutate container state. |
| analyze_local_logsA | Tail and optionally filter a log file. The path is resolved relative to a server-configured, sandboxed log directory -- absolute paths and '..' traversal are rejected. Supports a coarse severity filter (error_and_above / warning_and_above) and a case-insensitive substring search. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool targets a distinct subsystem: system metrics, Docker containers, and log files. There is no overlap in purpose or functionality; an agent can easily select the correct tool based on the resource it needs to access.
All tool names follow a consistent snake_case verb_noun pattern: get_system_metrics, manage_docker_containers, analyze_local_logs. The verbs clearly indicate the action (get, manage, analyze) and the nouns specify the target, making the pattern predictable and readable.
With only 3 tools, the server is tightly scoped to its stated purpose of infrastructure and metrics. Each tool covers a major area (host metrics, container introspection, log analysis) and earns its place without redundancy or bloat.
The tool set covers core infrastructure monitoring needs: system resource metrics, Docker container state and logs, and local log tailing/filtering. Minor gaps exist, such as network metrics or process-level details, but these are not critical for the primary workflows and can be worked around.