Container Manager Mcp

CLI or API | MCP

Version: 3.3.0

Documentation — Installation, deployment, usage across the API, CLI, MCP, and A2A agent interfaces, and the multi-host control plane are maintained in the official documentation.

Overview

Container Manager Mcp is a production-grade Agent and Model Context Protocol (MCP) server designed to interface directly with Container Manager - manage Docker, Docker Swarm, Podman, and Kubernetes containers and workloads. MCP+A2A Servers By default!.

Full coverage across all three engines: Docker (incl. Swarm/service/stack/config/secret/node operations via cm_docker_swarm), Podman (incl. pod/kube operations, generate/play kube, checkpoint/restore via cm_podman), and a complete Kubernetes surface (RKE2 / k3s / vanilla) spanning workloads, config, networking, storage, RBAC, cluster admin, governance, and observability through 8 themed cm_k8s_* tools built on the official kubernetes Python client. A cm_multi_context tool lets an agent fan out operations across multiple Docker/Podman/Swarm/Kubernetes contexts in parallel, and cm_ingest_inventory feeds Docker, Swarm, and Kubernetes resources into the ontology-driven Knowledge Graph as typed nodes.

Key Features

• Consolidated Action-Routed MCP Tools: Minimizes token overhead and eliminates tool bloat in LLM contexts by grouping methods into optimized, togglable tool modules.
• Full Docker + Swarm + Podman + Kubernetes Coverage: First-class support for Docker (incl. Swarm/service/stack/config/secret/node ops), rootless Podman (incl. pods, generate/play kube, checkpoint/restore), and a full Kubernetes surface (RKE2 / k3s / vanilla) across workloads, config, networking, storage, RBAC, cluster admin, governance, and observability. See Kubernetes below.
• Multi-Context Parallel Operation: cm_multi_context fans operations out across multiple Docker, Podman, Swarm, and/or Kubernetes contexts at once (ThreadPoolExecutor-backed), with health checks and lazy reconnect.
• Enterprise-Grade Security: Complete support for Eunomia policies, OIDC token delegation, and granular execution context tracking.
• Integrated Graph Agent: Built-in Pydantic AI agent supporting the Agent Control Protocol (ACP) and standard Web interfaces (AG-UI).
• Ontology-Driven KG Ingestion: cm_ingest_inventory maps live Docker/Swarm/Kubernetes inventory (containers, images, volumes, networks, services, nodes, pods, deployments, namespaces, native k8s Services) into typed OWL/RDF nodes for cross-source reasoning.
• Native Telemetry & Tracing: Out-of-the-box OpenTelemetry exports and native Langfuse tracing.

Multi-Host & Zero-Script Remote Docker Orchestration

container-manager-mcp allows a single master instance of the MCP server on the operator's controller to route container and volume operations securely to remote hosts over SSH standard tunneling.

• Unified Inventory: Connection endpoints are loaded dynamically from the XDG shared inventory at ~/.config/agent-connector-sdk/inventory.yml (.yml preferred; a legacy inventory.yaml is still read when no .yml exists).
• Zero TCP Socket Exposure: Operations route directly over the standard SSH channel securely, removing the must expose Docker socket TCP ports.

Shared inventory: the cm_* host aliases the operator pass as host come from the same inventory.yml used by tunnel-manager — define the operator's fleet once. Create and validate it with tunnel-manager inventory init / tunnel-manager inventory doctor. See tunnel-manager's Inventory guide for the full schema, template, and override options.

To configure and use the multi-host remote routing, see the detailed Multi-Host Architecture Guide.

CLI or API

This agent wraps the Container Manager - manage Docker, Docker Swarm, and Podman containers. MCP+A2A Servers By default! API. The operator can interact with it programmatically or via its integrated execution entrypoints.

Detailed instructions on how to use the underlying API wrappers, extended schema bindings, and developer SDK references are maintained in docs/index.md.

Environment doctor

Not sure the operator's environment is wired up? Run the guided doctor first. It probes every surface with real checks — python client libs + CLIs, CONTAINER_MANAGER_TYPE / toggles / K8S_CONTEXTS parsing, the tunnel-manager SSH inventory (and per-host reachability), the docker / podman daemons, and each kubernetes context — and prints concrete remediation for anything that is not OK, so the operator are walked through connecting to the operator's environments. Available as the container-manager-doctor CLI and the cm_doctor MCP tool.

container-manager-doctor                       # diagnose everything (exit 1 if any FAIL)
container-manager-doctor --guided              # + probe every inventory host
container-manager-doctor --backend inventory --host <alias>
container-manager-doctor --backend kubernetes --context <ctx>
container-manager-doctor --backend docker --host <alias>
container-manager-doctor --json                # machine-readable report

The cm_doctor MCP tool mirrors it: action=run for a full sweep, or a focused check_backends / check_inventory / check_docker / check_podman / check_kubernetes. Each check returns {name, category, status: ok|warn|fail, detail, remediation} plus a summary. Start here, then follow the container-manager configuration walkthrough.

Save a Kubernetes environment (register a kubeconfig context)

Dynamically add a kube context to the kubeconfig cm reads ($KUBECONFIG first entry, else ~/.kube/config) so the operator can reuse it later (via use_context / CONTAINER_MANAGER_KUBECONTEXT / K8S_CONTEXTS). The merge is non-destructive — existing entries are never clobbered, and a context-name collision errors unless the operator pass --overwrite. Available as the container-manager-save-context CLI and the cm_k8s_cluster save_context MCP action (both call the same core function). Secrets (tokens, key data) are kept out of logs; cert/key files are embedded as base64 so the saved context is portable.

Four credential input modes, each saved under a context name the operator choose:

1. URL + token — server URL + bearer token (ServiceAccount / OIDC id-token).
2. URL + client-cert + client-key + CA — mTLS (how an RKE2 admin kubeconfig authenticates); certs accept file paths or inline PEM/base64.
3. URL + username + password → OIDC — for OIDC-backed clusters only. The Kubernetes API server does not accept plain username/password (basic auth was removed), so this drives an OIDC resource-owner password grant against the issuer and embeds the resulting id-token; it requires --oidc-issuer + --oidc-client-id and fails clearly if they are missing.
4. Import a kubeconfig — merge an existing file/blob, or capture the cluster the operator are currently on.

# 1. URL + token
container-manager-save-context --name prod --server https://10.0.0.10:6443 \
    --token "$TOKEN" --ca-cert /path/to/ca.crt --namespace default --use

# 2. URL + client cert/key + CA (mTLS, e.g. RKE2 admin)
container-manager-save-context --name rke2 --server https://10.0.0.10:6443 \
    --client-cert ./client.crt --client-key ./client.key --ca-cert ./ca.crt

# 3. URL + username + password -> OIDC login (id-token embedded)
container-manager-save-context --name oidc-dev --server https://10.0.0.10:6443 \
    --username alice --password "$PW" \
    --oidc-issuer https://keycloak/realms/homelab --oidc-client-id kubernetes

# 4. import + merge an existing kubeconfig (file or raw YAML on stdin)
container-manager-save-context --from-file ./other-kubeconfig
cat cluster.yaml | container-manager-save-context --from-yaml -

# capture the cluster you are currently on (in-cluster SA token+CA, or the
# current kubeconfig context) and save a portable copy under a new name
container-manager-save-context --name exported --capture-current --use

# on name collision, --overwrite replaces; otherwise it errors
container-manager-save-context --name prod --overwrite --from-file ./prod-kubeconfig

After saving, the context is loaded and list_nodes is called to validate reachability (skip with --no-validate); the node count or a clear error is returned. The cm_k8s_cluster MCP action mirrors every flag (action=save_context, context_name, server/token/client_cert/client_key/ca_cert/ insecure_skip_tls_verify, username/password/oidc_issuer/oidc_client_id/ oidc_client_secret, source_file/source_yaml, capture_current, overwrite, use, validate).

MCP

This server use dynamic Action-Routed tools to optimize token overhead and maximize IDE compatibility.

Available MCP Tools

Auto-generated — do not edit (synced by the mcp-readme-table pre-commit hook).

Condensed action-routed tools (MCP_TOOL_MODE=condensed)

Verbose 1:1 API-mapped tools (MCP_TOOL_MODE=verbose or both)

23 action-routed tool(s) · 292 verbose 1:1 tool(s). Each is enabled unless its <DOMAIN>TOOL toggle is set false; MCP_TOOL_MODE selects the surface (intent default — the six verb-tools, granular set loaded on demand · condensed action-routed · verbose 1:1 · both). Auto-generated — do not edit.

Detailed tool schemas, parameter shapes, and validation constraints are preserved in docs/usage.md.

Kubernetes

container-manager-mcp ships full Kubernetes coverage (RKE2 / k3s / vanilla) through the official kubernetes Python client, exposed as 8 themed, action-routed MCP tools (replacing an earlier, messier tool sprawl):

Two details worth knowing:

• patch_resource (on cm_k8s_config) is a generic patch action supporting strategic / merge / json patch types against any resource kind — use it when there's no dedicated action for a field-level update.
• True core Services vs. Swarm-parity services — cm_k8s_networking's list_k8s_services / get_k8s_service / create_k8s_service / delete_k8s_service operate on real Kubernetes Service objects. This is distinct from cm_multi_context's Swarm-parity list_services, which is Deployment-shaped for cross-backend comparability.

Kubernetes access is configured via CONTAINER_MANAGER_TYPE=kubernetes and CONTAINER_MANAGER_KUBECONTEXT (see Environment Variables); for operating multiple clusters at once, see K8S_CONTEXTS / cm_multi_context below. For a full worked walkthrough of the tool surface, see the container-manager-kubernetes-operations skill and docs/usage.md.

Multi-Context Operation

cm_multi_context (toggle MULTICONTEXTTOOL) lets a single MCP call operate across multiple Docker, Podman, Swarm, and/or Kubernetes contexts at once — configured via K8S_CONTEXTS, DOCKER_CONTEXTS, SWARM_CONTEXTS, and their DEFAULT_*_CONTEXT defaults (MULTI_CONTEXT_MODE=True routes every call through it). Fan-out is parallel (ThreadPoolExecutor-backed) with per-backend health checks and lazy reconnect, so an agent can compare, migrate between, or simultaneously act on multiple clusters/engines/hosts in one call. See the container-manager-multi-context skill and docs/usage.md for examples.

Dynamic Tool Selection & Visibility

This MCP server supports dynamic toolset selection and visibility filtering at runtime. This allows the operator to restrict the set of exposed tools to prevent blowing up the LLM's context window.

The operator can configure tool filtering via multiple input channels:

• CLI Arguments: Pass --tools or --toolsets (or their disabled counterparts --disabled-tools and --disabled-toolsets) during startup.
• Environment Variables: Define standard environment variables:
  • MCP_ENABLED_TOOLS / MCP_DISABLED_TOOLS
  • MCP_ENABLED_TAGS / MCP_DISABLED_TAGS
• HTTP SSE Request Headers: Pass custom headers during transport initialization:
  • x-mcp-enabled-tools / x-mcp-disabled-tools
  • x-mcp-enabled-tags / x-mcp-disabled-tags
• HTTP SSE Request Query Parameters: Append query parameters directly to the operator's transport connection URL:
  • ?tools=tool1,tool2
  • ?tags=tag1

When query strings or parameters are supplied, an LLM-free Knowledge Graph resolution layer (using DynamicToolOrchestrator) matches query intents against known tool tags, names, or descriptions, with safe fallback and automated 24-hour background cache refreshing.

MCP Configuration Examples

Install the connector-focused [mcp] extra. Examples use container-manager-mcp[mcp] to add FastMCP / FastAPI through agent-connector-sdk; the required Agent Connector SDK core still carries epistemic-graph[full]. The [agent-runtime] extra additionally enables model orchestration.

stdio Transport (local IDEs — Cursor, Claude Desktop, VS Code)

{
  "mcpServers": {
    "container-manager-mcp": {
      "command": "uvx",
      "args": [
        "--from",
        "container-manager-mcp[mcp]",
        "container-manager-mcp"
      ],
      "env": {
        "MCP_TOOL_MODE": "intent",
        "COMPOSETOOL": "True",
        "CONTAINERTOOL": "True",
        "CONTAINER_MANAGER_HEALTH_AGGREGATE_S": "3600",
        "CONTAINER_MANAGER_HEALTH_INGEST": "true",
        "CONTAINER_MANAGER_TYPE": "docker",
        "DOCKERSWARMTOOL": "True",
        "DOCTORTOOL": "True",
        "HEALTH_CHECK_TTL_SECONDS": "30",
        "IMAGETOOL": "True",
        "INFOTOOL": "True",
        "INVENTORYTOOL": "True",
        "K8SCLUSTERTOOL": "True",
        "K8SCONFIGTOOL": "True",
        "K8SGOVERNANCETOOL": "True",
        "K8SNETWORKINGTOOL": "True",
        "K8SOBSERVABILITYTOOL": "True",
        "K8SRBACTOOL": "True",
        "K8SSTORAGETOOL": "True",
        "K8SWORKLOADSTOOL": "True",
        "MISCTOOL": "True",
        "MULTICONTEXTTOOL": "True",
        "MULTI_CONTEXT_MODE": "True",
        "NETWORKTOOL": "True",
        "PODMANTOOL": "True",
        "PODMAN_ENABLED": "true",
        "SPECIALIST_DEPLOYMENTTOOL": "True",
        "SWARMTOOL": "True",
        "SYSTEMTOOL": "True",
        "VOLUMETOOL": "True"
      }
    }
  }
}

Runtime references require an alias-aware launcher such as Arbora. Other launchers must omit those entries and inject the resolved values through their own runtime secret boundary.

Streamable-HTTP Transport (networked / production)

{
  "mcpServers": {
    "container-manager-mcp": {
      "command": "uvx",
      "args": [
        "--from",
        "container-manager-mcp[mcp]",
        "container-manager-mcp",
        "--transport",
        "streamable-http",
        "--port",
        "8000"
      ],
      "env": {
        "TRANSPORT": "streamable-http",
        "HOST": "127.0.0.1",
        "PORT": "8000",
        "MCP_TOOL_MODE": "intent",
        "COMPOSETOOL": "True",
        "CONTAINERTOOL": "True",
        "CONTAINER_MANAGER_HEALTH_AGGREGATE_S": "3600",
        "CONTAINER_MANAGER_HEALTH_INGEST": "true",
        "CONTAINER_MANAGER_TYPE": "docker",
        "DOCKERSWARMTOOL": "True",
        "DOCTORTOOL": "True",
        "HEALTH_CHECK_TTL_SECONDS": "30",
        "IMAGETOOL": "True",
        "INFOTOOL": "True",
        "INVENTORYTOOL": "True",
        "K8SCLUSTERTOOL": "True",
        "K8SCONFIGTOOL": "True",
        "K8SGOVERNANCETOOL": "True",
        "K8SNETWORKINGTOOL": "True",
        "K8SOBSERVABILITYTOOL": "True",
        "K8SRBACTOOL": "True",
        "K8SSTORAGETOOL": "True",
        "K8SWORKLOADSTOOL": "True",
        "MISCTOOL": "True",
        "MULTICONTEXTTOOL": "True",
        "MULTI_CONTEXT_MODE": "True",
        "NETWORKTOOL": "True",
        "PODMANTOOL": "True",
        "PODMAN_ENABLED": "true",
        "SPECIALIST_DEPLOYMENTTOOL": "True",
        "SWARMTOOL": "True",
        "SYSTEMTOOL": "True",
        "VOLUMETOOL": "True"
      }
    }
  }
}

Alternatively, connect to a pre-deployed Streamable-HTTP instance by url:

{
  "mcpServers": {
    "container-manager-mcp": {
      "url": "http://localhost:8000/container-manager-mcp/mcp"
    }
  }
}

Run a reviewed container image as a least-privilege stdio child (no listener or published port):

docker run -i --rm \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --pids-limit=256 \
  --tmpfs /tmp:rw,noexec,nosuid,nodev,size=64m \
  -e TRANSPORT=stdio \
  -e MCP_TOOL_MODE=intent \
  -e COMPOSETOOL=True \
  -e CONTAINERTOOL=True \
  -e CONTAINER_MANAGER_HEALTH_AGGREGATE_S=3600 \
  -e CONTAINER_MANAGER_HEALTH_INGEST=true \
  -e CONTAINER_MANAGER_TYPE=docker \
  -e DOCKERSWARMTOOL=True \
  -e DOCTORTOOL=True \
  -e HEALTH_CHECK_TTL_SECONDS=30 \
  -e IMAGETOOL=True \
  -e INFOTOOL=True \
  -e INVENTORYTOOL=True \
  -e K8SCLUSTERTOOL=True \
  -e K8SCONFIGTOOL=True \
  -e K8SGOVERNANCETOOL=True \
  -e K8SNETWORKINGTOOL=True \
  -e K8SOBSERVABILITYTOOL=True \
  -e K8SRBACTOOL=True \
  -e K8SSTORAGETOOL=True \
  -e K8SWORKLOADSTOOL=True \
  -e MISCTOOL=True \
  -e MULTICONTEXTTOOL=True \
  -e MULTI_CONTEXT_MODE=True \
  -e NETWORKTOOL=True \
  -e PODMANTOOL=True \
  -e PODMAN_ENABLED=true \
  -e SPECIALIST_DEPLOYMENTTOOL=True \
  -e SWARMTOOL=True \
  -e SYSTEMTOOL=True \
  -e VOLUMETOOL=True \
  registry.example.invalid/container-manager-mcp@sha256:<digest> container-manager-mcp

For containerized network HTTP, supply an authenticated TLS ingress (or direct server TLS), exact MCP_ALLOWED_HOSTS, and an exact trusted-proxy CIDR policy through the operator-owned deployment profile. The generator does not emit an unauthenticated non-loopback listener.

Auto-generated from the code-read env surface (MCP_TOOL_MODE + package vars) — do not edit.

Additional Deployment Options

container-manager-mcp can run as a local stdio process or container, or behind a remote network boundary. The Deployment guide carries the detailed transport contract.

• Local container — launch a reviewed immutable image as a least-privilege stdio child with no listener or published port.
• Remote URL — connect through an operator-supplied authenticated HTTPS ingress. Keep its URL, outbound identity references, trust profile, and exact MCP_ALLOWED_HOSTS in AgentConfig.

Environment Variables

Package environment variables

Inherited agent-connector-sdk variables (apply to every connector)

54 package + 16 inherited variable(s). Auto-generated from .env.example + the shared agent-connector-sdk set — do not edit.

Every variable is listed in the auto-generated table above (package vars from .env.example + the inherited agent-connector-sdk surface). A small number of pointers:

• Tool toggles — each action-routed tool can be disabled via its <DOMAIN>TOOL toggle; the tool ↔ toggle mapping is in the Available MCP Tools table above.
• Multi-host control plane — remote host endpoints load from the XDG shared inventory ~/.config/agent-connector-sdk/inventory.yml (.yml preferred, .yaml legacy fallback), managed via tunnel-manager inventory init|doctor (see Multi-Host guide).

See .env.example for a copy-paste starting point.

Agent

This repository features a fully integrated Pydantic AI Graph Agent. It communicates over the Agent Control Protocol (ACP) and interacts smoothly with the Agent Web UI (AG-UI) and Terminal interface.

Running the Agent CLI

To start the interactive command-line agent:

# Run the agent server
container-manager-agent --provider openai --model-id gpt-4o

Docker Compose Orchestration

version: '3.8'

services:
  container-manager-mcp-mcp:
    image: example/container-manager-mcp:mcp
    container_name: container-manager-mcp-mcp
    hostname: container-manager-mcp-mcp
    restart: always
    env_file:
      - ../.env
    environment:
      - PYTHONUNBUFFERED=1
      - HOST=0.0.0.0
      - PORT=8000
      - TRANSPORT=streamable-http
    ports:
      - "8000:8000"
    healthcheck:
      test: ["CMD", "python3", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 10s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

    image: example/container-manager-mcp@sha256:<digest>
    container_name: container-manager-mcp-agent
    hostname: container-manager-mcp-agent
    restart: always
    depends_on:
      - container-manager-mcp-mcp
    env_file:
      - ../.env
    command: [ "container-manager-agent" ]
    environment:
      - PYTHONUNBUFFERED=1
      - HOST=0.0.0.0
      - PORT=9019
      - MCP_URL=http://container-manager-mcp-mcp:8000/mcp
      - PROVIDER=${PROVIDER:-openai}
      - MODEL_ID=${MODEL_ID:-gpt-4o}
      - ENABLE_WEB_UI=True
      - ENABLE_OTEL=True
    ports:
      - "9019:9019"
    healthcheck:
      test: ["CMD", "python3", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:9019/health')"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 10s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Detailed graph node architecture explanations, custom skill configurations, and agentic trace guides are available in docs/deployment.md.

Security & Governance

Built directly upon the enterprise-ready agent-connector-sdk core, standard security parameters are fully supported:

Access Control & Policy Enforcement

• Eunomia Policies: Fine-grained, policy-driven tool authorization. Supports none, local embedded (mcp_policies.json), or centralized remote modes.
• OIDC Token Delegation: Compliant with RFC 8693 token exchange for flowing authenticating user credentials from Web UI / ACP → Agent → MCP.
• Scoped Credentials: Execution context runs restricted to the specific caller identity.

Runtime Security Grid

Installation

Pick the extra that matches what the operator want to run:

# Connector-focused MCP server (includes the shared graph engine)
uv pip install "container-manager-mcp[mcp]"

# Agent runtime (adds model orchestration to the shared graph engine)

# Everything (development)
uv pip install "container-manager-mcp[all]"      # or: python -m pip install "container-manager-mcp[all]"

Container images (:mcp)

One multi-stage docker/Dockerfile builds the MCP-only image (--target mcp):

docker build --target mcp   -t example/container-manager-mcp:mcp    docker/   # connector-focused MCP server

agent (immutable agent digest) with a co-located :mcp sidecar.

Knowledge-graph database (epistemic-graph)

Agent Connector SDK core dependency (epistemic-graph[full]). The [mcp] extra keeps deployments can use the bundled engine. For production or shared state, run epistemic-graph as a dedicated database service and configure the runtime to use it. Deployment recipes (single-node + Raft HA), connection configuration, and architecture diagrams are documented in the epistemic-graph deployment guide.

Documentation

The complete documentation is published as the official documentation site and is the recommended reference for installation, deployment, and day-to-day operation.

AGENTS.md is the canonical contributor/agent guidance.

Skills

Alongside the MCP tools, container_manager_mcp/skills/ ships Universal Skills that guide an agent through common operational flows:

container-manager-kubernetes-operations, container-manager-podman-operations, container-manager-multi-context, and container-manager-config-walkthrough are new; lifecycle, swarm, and kg-ingestion were updated for the expanded tool surface.

Repository Owners

Contribute

Contributions are welcome! Please ensure code quality by running local checks before submitting pull requests:

• Format code using ruff format .
• Lint code using ruff check .
• Validate type-safety with mypy .
• Ran test suites using pytest

Governed capability contract

This package ships a compact canonical skill surface with specialist procedures kept as referenced workflows. The current MCP tools, skill metadata, connector_manifest.yml, ontology, mappings, shapes, fixtures, migrations, tool-schema fingerprints, and certification metadata form one versioned capability contract. Validate them together; do not rely on stale tool names or historical per-task skill wrappers.

Runtime endpoints, credentials, certificate trust, tenant identity, retention, and observability policy are deployment inputs and are never packaged values. See Configuration, trust, and privacy before enabling a network transport, connector ingestion, Arbora delegation, or trace export.