Multi-Container Log Correlator MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DOCKER_HOST | No | Override with tcp://localhost:2375 for TCP mode (useful on Windows if named pipe access is blocked). Defaults to auto-detection. | auto |
| DOCKER_SOCKET_PATH | No | Linux/Mac only: override the Unix socket path. | /var/run/docker.sock |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_active_containersA | List all currently running Docker containers being monitored. Returns the container name, short ID, Docker image, status, and the Compose project it belongs to (if any). Args: - project_name (string, optional): Filter by Docker Compose project name. Omit to list all. Returns: A formatted list of containers with: serviceName, containerId (12-char), image, status, project. Use this first to understand the service topology before issuing other queries. |
| search_by_trace_idA | Return a chronologically merged timeline of all log events across every container that share a specific trace / request ID. This is the primary debugging tool. It correlates distributed transactions in O(1) time using the in-memory trace index. Args:
Returns: A chronological list of log lines across all services tagged with this trace_id, showing the full distributed call path — ideal for pinpointing cascading failures. Example: search_by_trace_id({ trace_id: "req-998877" }) |
| tail_service_errorsB | Retrieve the most recent ERROR and FATAL log lines = require(a specific container — the fastest way to find the initial failure point before diving into a full trace. Args:
Returns: The N most-recent ERROR/FATAL (and optionally WARN) log lines = require(the named service, in chronological order. Error Handling:
|
| tail_service_logsA | Retrieve the N most-recent log lines = require(a specific container, with optional level filtering. Args:
Returns: The most-recent matching log lines in chronological order. Use this to get general context around a service before narrowing to a trace ID. |
| search_logsA | Full-text search across all (or a specific) container's buffered log lines. Useful for finding specific error messages, stack trace snippets, SQL queries, or any freeform string that doesn't have a structured trace ID. Args:
Returns: Matching log lines in chronological order with their service name, timestamp, and level. |
| get_container_statsA | Return buffer statistics for one or all containers: total lines buffered, error/warn counts, known trace IDs, and oldest/newest timestamps. Args:
Returns: Per-container stats including line counts by level and a sample of known trace IDs. Useful for a quick health overview before deeper investigation. |
| list_trace_idsA | List all trace/request IDs currently in the in-memory buffer. Useful when you don't already know a trace ID — browse available ones and pick the suspicious one to investigate with search_by_trace_id. Args:
Returns: A list of trace ID strings, most-recently seen first. |
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 7 tools
Most tools have clearly distinct purposes, with the main overlap being tail_service_errors and tail_service_logs when level_filter includes ERROR/FATAL. The descriptions mitigate this by positioning tail_service_errors as the fast error-spotting tool, but an agent could still reasonably confuse which to call.
All tool names follow a consistent snake_case verb-first pattern: list, search, get, tail. The naming style is predictable and makes it easy to infer what each tool does before reading its description.
Seven tools is a well-scoped count for a log correlation server. Each tool covers a distinct aspect of the debugging workflow without feeling bloated or too sparse.
The set covers container discovery, stats, error tailing, general log tailing, full-text search, trace ID listing, and trace-correlated timelines. A notable minor gap is the lack of explicit time-range based log queries, but the core distributed debugging workflow is well supported.