Interact with local Docker daemon: list containers, fetch logs, restart, and inspect containers.
Interact with local Kubernetes cluster: list pods, get pod logs, and describe pods.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@local-devops-mcp list my running Docker containers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides tools for local DevOps tasks, enabling AI assistants to interact with your local Docker environment, Kubernetes clusters, and system logs.
This server usesTOON (Token-Oriented Object Notation) for tool outputs to optimize token usage for LLMs.
Interact with your local Docker daemon:
docker_list_containers: List running or all containers.
docker_logs: Fetch logs from a container (with error highlighting 🔴).
docker_restart: Restart a specific container.
docker_inspect: Inspect container details.
Interact with your local Kubernetes cluster (uses ~/.kube/config):
k8s_list_pods: List pods in a namespace.
k8s_pod_logs: Get logs from a pod.
k8s_describe_pod: Get detailed pod information.
Access local system information:
system_open_ports: List open listening ports (requires lsof).
system_logs: Read system logs (e.g., /var/log/system.log).
Related MCP server: Docker MCP Server
npx (Recommended)You can run the server directly without installation:
npx local-devops-mcpTo use this server with Claude Desktop, add the following to your claude_desktop_config.json:
{
"mcpServers": {
"local-devops": {
"command": "npx",
"args": ["-y", "local-devops-mcp"]
}
}
}Clone the repository:
git clone https://github.com/nguyentrantung205/local-devops-mcp.git
cd local-devops-mcpInstall dependencies:
npm installBuild the project:
npm run buildRun the server:
node build/index.jsNode.js: v18 or higher.
Docker: Docker Desktop or Docker Engine must be running locally.
Kubernetes: kubectl configured with a valid ~/.kube/config (optional, only for K8s tools).
Permissions: The user running the server needs permissions to access the Docker socket and read system logs.
See TESTING.md for instructions on how to test the server locally.
ISC
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Container ID or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tail | No | Number of lines to show from the end of the logs | |
| containerId | Yes | Container ID or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | Namespace to list pods from (default: default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Pod name | |
| container | No | Container name (optional) | |
| namespace | No | Namespace (default: default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0docker_inspectdocker_logsk8s_list_podsk8s_pod_logsEach tool has a distinct prefix (docker or k8s) and action (logs, inspect, list_pods, pod_logs), making them clearly distinguishable even without descriptions.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., docker_logs, k8s_list_pods), and the prefix consistently indicates the subsystem.
With only 4 tools for a broad domain like local devops, the set feels too sparse to cover common operations, though each tool is distinct.
Obvious gaps: Docker only has logs and inspect (no run, stop, etc.) and Kubernetes only has list pods and pod logs (no get, delete, etc.), leaving agents unable to complete basic workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
A Model Context Protocol server for Wix AI tools
The Google GKE MCP server is a managed Model Context Protocol server that provides AI applications with tools to manage Google Kubernetes Engine (GKE) clusters and Kubernetes resources. It exposes a structured, discoverable interface that allows AI agents to interact with GKE and Kubernetes APIs, enabling them to inspect cluster configurations, retrieve Kubernetes resource YAMLs, monitor operations like cluster upgrades, diagnose issues, and optimize costs—all without needing to parse text output or use complex kubectl commands.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nguyentrantung205/local-devops-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
