MCP dla infrastruktury: Docker MCP Toolkit, Kubernetes i Terraform

Serwery MCP dla infrastruktury dają Claude Code, Codeksowi i Cursorowi ograniczony dostęp do działających systemów: serwer MCP Kubernetesa czyta stan klastra, serwer MCP Terraforma czyta Terraform Registry i przebiegi w HCP Terraform, a Docker MCP Toolkit uruchamia serwery w kontenerach za jedną bramką. Podłączone tylko do odczytu pozwalają agentowi diagnozować i proponować, a zmiany trafiają na produkcję jako przejrzany kod.

Ta strona jest dla programistów, którzy odpowiadają za usługę od początku do końca, i dla tech leadów, którzy decydują, czego agent może dotknąć w klastrze. Na stagingu pod checkout restartuje się co 40 sekund. Uruchamiasz kubectl get pods, kubectl describe, kubectl logs --previous, wklejasz agentowi trzy ekrany wyników, a on prosi o zdarzenia, których nie skopiowałeś. Następnego dnia ten sam agent pisze moduł Terraforma z argumentem S3, który provider usunął dwie wersje główne temu.

Nie znasz jeszcze MCP? Zacznij od przeglądu MCP, który wyjaśnia serwery, transporty i zakresy, zanim ta strona podłączy je do klastra.

Co zyskujesz dzięki MCP dla infrastruktury

Konfigurację serwera MCP Kubernetesa tylko do odczytu: osobne konto ServiceAccount, plik TOML z read_only = true i Secrety zablokowane na poziomie serwera
Gotowy prompt, który prowadzi od CrashLoopBackOff do przyczyny i pull requesta z poprawką manifestu
Konfigurację serwera MCP Terraforma, która zaczyna od publicznego rejestru i dodaje HCP Terraform bez włączania apply
Pętlę infrastruktury jako kodu: sprawdzenie w rejestrze, moduł, plan w HCP Terraform, przegląd, apply wykonane przez człowieka
Zmierzony koszt kontekstu wtyczki ze skillami HashiCorp oraz pułapki we wpisach katalogu i wtyczkach każdego serwera

Który serwer MCP dla infrastruktury do czego służy?

Trzy serwery odpowiadają na różne pytania, a skille HashiCorp pokrywają czwarte: jak pisać kod, a nie co mówi działający system.

Element	Na jakie pytanie odpowiada	Jak działa	Kontrola zapisu	Popularność (2026-09-26)
Kubernetes MCP Server (organizacja `containers` na GitHubie, społeczność)	Co robi klaster i dlaczego to obciążenie pada?	Lokalnie przez stdio (`npx`, `uvx`, plik binarny lub obraz); komunikuje się bezpośrednio z serwerem API Kubernetesa, bez `kubectl`	`read_only = true` w TOML oraz RBAC kubeconfiga, którego używa	★2.1k; npm `kubernetes-mcp-server` 0.0.67
Terraform MCP Server (HashiCorp)	Jak wygląda aktualne API providera lub modułu i co pokazał plan w HCP Terraform?	Obraz Dockera `hashicorp/terraform-mcp-server`, stdio lub Streamable HTTP	Bez tokena: tylko 9 publicznych narzędzi `registry`; z tokenem filtruj przez `--toolsets` lub `--tools`. Apply, discard, cancel, force-unlock i usuwanie workspace’ów, projektów i zespołów wymagają `ENABLE_TF_OPERATIONS=true`	★1.5k; wtyczka `terraform@claude-plugins-official`: 10 280 instalacji
Docker MCP Toolkit / Gateway (Docker)	Jak uruchomić wiele serwerów w kontenerach, z sekretami w pęku kluczy, dla każdego klienta?	`docker mcp gateway run`, jeden profil współdzielony przez klientów	Listy dozwolonych narzędzi w profilu; sekrety domyślnie blokowane w ruchu narzędzi	`docker/mcp-gateway` ★1.6k; repozytorium katalogu ★558
Skille HashiCorp (HashiCorp)	Jak powinien być napisany i przetestowany ten Terraform?	16 skilli do Terraforma i 4 do Packera; wtyczka albo pojedyncze skille	Nie dotyczy: skille dodają instrukcje, nie dostęp	★875; wtyczka `terraform@hashicorp` 1.0.0

Gwiazdki pochodzą z GitHuba, a liczba instalacji z katalogu wtyczek na claude.com; obie odczytano 2026-09-26. Gwiazdki mierzą zainteresowanie repozytorium, a nie użycie serwera.

Skonfiguruj serwer MCP Kubernetesa tylko do odczytu

Serwer używa tego kubeconfiga, który znajdzie. Jeśli to twój osobisty kontekst administratora, agent ma twoje uprawnienia administratora, a read_only = true to jedyne, co dzieli niejasny prompt od resources_delete. Daj mu więc własną tożsamość, żeby limit egzekwował RBAC klastra, nawet jeśli konfiguracja serwera okaże się błędna.

Utwórz konto ServiceAccount tylko do odczytu. Poniższe polecenia wiążą wbudowaną rolę ClusterRole view w jednej przestrzeni nazw. view czyta pody, logi, zdarzenia i Deploymenty, ale nie czyta Secretów.

# Terminal, z twoim zwykłym kontekstem administratora
kubectl create namespace mcp
kubectl create serviceaccount mcp-viewer -n mcp
kubectl create rolebinding mcp-viewer-staging --clusterrole=view \
  --serviceaccount=mcp:mcp-viewer -n staging
kubectl auth can-i list pods --as=system:serviceaccount:mcp:mcp-viewer -n staging    # yes
kubectl auth can-i delete pods --as=system:serviceaccount:mcp:mcp-viewer -n staging  # no
kubectl auth can-i get secrets --as=system:serviceaccount:mcp:mcp-viewer -n staging  # no

Po kubectl create clusterrolebinding … --clusterrole=view sięgnij tylko wtedy, gdy agent musi czytać wszystkie przestrzenie nazw.

Zbuduj osobny kubeconfig z krótkotrwałym tokenem. kubectl create token (Kubernetes 1.24+) wydaje token, który sam wygasa.

TOKEN="$(kubectl create token mcp-viewer -n mcp --duration=8h)"
API_SERVER="$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')"
kubectl config view --minify --raw \
  -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d > /tmp/mcp-ca.crt
KCFG="$HOME/.kube/mcp-viewer.kubeconfig"
kubectl config --kubeconfig="$KCFG" set-cluster mcp --server="$API_SERVER" \
  --certificate-authority=/tmp/mcp-ca.crt --embed-certs=true
kubectl config --kubeconfig="$KCFG" set-credentials mcp-viewer --token="$TOKEN"
kubectl config --kubeconfig="$KCFG" set-context mcp --cluster=mcp --user=mcp-viewer --namespace=staging
kubectl config --kubeconfig="$KCFG" use-context mcp
chmod 600 "$KCFG"; rm /tmp/mcp-ca.crt

Jeśli kubeconfig twojego klastra wskazuje plik certificate-authority zamiast osadzonych danych, podaj bezpośrednio tę ścieżkę.

Napisz plik TOML serwera. TOML to zalecane miejsce na ustawienia. Wersja 0.0.67 nadal przyjmuje flagi takie jak --read-only i --toolsets, ale następne wydanie je usuwa (zmiana jest na gałęzi main na dzień 2026-09-26), więc trzymaj read_only w pliku, zamiast podawać --read-only.
~/.config/kubernetes-mcp-server.toml
```
read_only = true                      # only tools annotated readOnlyHint=true are exposed
toolsets = ["core", "config"]         # the default pair; add "helm" only if you need helm_list
disabled_tools = ["configuration_view"]

[[denied_resources]]                  # belt and braces on top of RBAC
group = ""
version = "v1"
kind = "Secret"
```
configuration_view wypisuje kubeconfig jako YAML. Przy stdio, jak w tej konfiguracji, jest domyślnie dostępne, więc je wyłącz.
Zarejestruj serwer. Przypnij wersję zamiast @latest, żeby nowe wydanie nie zmieniło ci zestawu narzędzi w środku incydentu.
Okno terminala
# Terminal, katalog główny repozytorium. Pojedyncze cudzysłowy zostawiają ${HOME}; Claude Code rozwija je przy starcie claude mcp add kubernetes -s project \ -e 'KUBECONFIG=${HOME}/.kube/mcp-viewer.kubeconfig' \ -- npx -y kubernetes-mcp-server@0.0.67 --config '${HOME}/.config/kubernetes-mcp-server.toml'
Okno terminala
# Zapisuje [mcp_servers.kubernetes] do ~/.codex/config.toml; $HOME rozwija tu twoja powłoka codex mcp add kubernetes --env KUBECONFIG=$HOME/.kube/mcp-viewer.kubeconfig \ -- npx -y kubernetes-mcp-server@0.0.67 --config $HOME/.config/kubernetes-mcp-server.toml
// ~/.cursor/mcp.json — użyj ścieżek bezwzględnych { "mcpServers": { "kubernetes": { "command": "npx", "args": ["-y", "kubernetes-mcp-server@0.0.67", "--config", "/Users/you/.config/kubernetes-mcp-server.toml"], "env": { "KUBECONFIG": "/Users/you/.kube/mcp-viewer.kubeconfig" } } } }
Sprawdź, co widzi agent. Uruchom /mcp w Claude Code lub Codeksie albo otwórz ustawienia MCP w Cursorze. Przy read_only = true nie powinieneś widzieć żadnego narzędzia zapisu, np. pods_delete, pods_exec, pods_run, resources_create_or_update, resources_delete ani resources_scale.

Zdiagnozuj CrashLoopBackOff z agentem

Od tego przykładu zacznij. Działa tylko do odczytu i kończy się dowodami, które sprawdzisz w dwie minuty, a nie ścianą rozumowania.

Use the kubernetes MCP server, read-only. In namespace staging, find the pods of deployment checkout that are in CrashLoopBackOff.
For the newest one: get the pod, read the logs of the previous (crashed) container with previous=true and tail=200, and list Warning events for that pod.
Then get the Deployment and compare its image tag, env, resource limits, probes and mounted ConfigMaps with the last ReplicaSet that was healthy.
Report: the exit code and reason (for example OOMKilled, Error 1, failed liveness probe), the log lines that show the cause, the event that confirms it, and what changed between the two ReplicaSets.
Propose the fix as a diff to the manifest in deploy/k8s/checkout/ in this repository. Do not change anything in the cluster.

Czego się spodziewać: wywołań pods_list_in_namespace, pods_get, pods_log z previous: true, events_list z selektorem pól w rodzaju involvedObject.name=<pod> oraz resources_get dla Deploymentu i ReplicaSetów. Raport wskazuje jedną przyczynę razem z dowodem, na przykład „kod wyjścia 137, powód OOMKilled, limit pamięci obniżony z 512Mi do 256Mi w ostatnim wdrożeniu (rollout)”. Diff dotyczy pliku w repozytorium. Jeśli agent nie potrafi rozstrzygnąć między przyczynami, powinien powiedzieć, który dodatkowy odczyt to rozstrzygnie, zamiast zgadywać.

Poprawka idzie potem tą samą drogą co każda zmiana manifestu: pull request, CI i zwykłe wdrożenie. Gdy pod trzeba naprawić natychmiast, rollback (kubectl rollout undo deployment/checkout -n staging) uruchamia człowiek na własnych uprawnieniach; tożsamość agenta z założenia tego nie potrafi.

Apply the manifest fix you proposed to deploy/k8s/checkout/. In the pull request description include: the pod name, the exit reason, the three log lines and the event that prove the cause, and the ReplicaSet diff.
Add an acceptance check the reviewer can run after deploy: the kubectl commands that show zero restarts for 15 minutes and the Ready condition on all replicas.
Do not run kubectl apply. CI validates the manifest and the deploy pipeline applies it.

Skonfiguruj serwer MCP Terraforma, zaczynając od rejestru

Bez tokena serwer MCP Terraforma rejestruje tylko zestaw registry: dziewięć narzędzi, między innymi search_providers, get_provider_details, get_latest_provider_version, search_modules i get_module_details. Czytają publiczny Terraform Registry. To najtańsze lekarstwo na agenta, który pisze argumenty providera z pamięci. Flaga --toolsets ma domyślnie wartość all, więc gdy jest token, a nie podasz --toolsets, rejestrują się wszystkie zestawy: 56 narzędzi (61 z ENABLE_TF_OPERATIONS=true), w tym narzędzia zapisu, takie jak create_run, create_workspace i delete_variable_in_variable_set.

HCP Terraform lub Terraform Enterprise dodaj wtedy, gdy agent ma czytać workspace’y i plany. Do tego potrzebujesz TFE_TOKEN (oraz TFE_ADDRESS dla Terraform Enterprise) i zestawu terraform: 48 narzędzi do workspace’ów, przebiegów, planów, zmiennych i wersji stanu. Pięć z nich w ogóle się nie rejestruje, dopóki nie ustawisz ENABLE_TF_OPERATIONS=true: action_run (apply, discard, cancel), delete_workspace_safely, force_unlock_workspace, delete_project i delete_team. Bez tej zmiennej create_run oferuje tylko plan_and_apply z wyłączonym auto-apply, plan_only, refresh_state i allow_empty_apply; typy auto_approve i is_destroy pojawiają się dopiero z nią. Nie ustawiaj jej.

# Terminal, katalog główny repozytorium. Zapisuje .mcp.json z ${TFE_TOKEN}, które Claude Code rozwija przy starcie
claude mcp add terraform -s project \
  -e 'TFE_TOKEN=${TFE_TOKEN}' -e 'TFE_ADDRESS=${TFE_ADDRESS:-https://app.terraform.io}' \
  -- docker run -i --rm -e TFE_TOKEN -e TFE_ADDRESS \
  hashicorp/terraform-mcp-server:1.3.0 --toolsets=registry,terraform

Dla samego rejestru usuń obie pary -e i flagę --toolsets.

codex mcp add terraform -- docker run -i --rm -e TFE_TOKEN -e TFE_ADDRESS \
  hashicorp/terraform-mcp-server:1.3.0 --toolsets=registry,terraform

Potem przekaż obie zmienne z powłoki, zamiast wpisywać token do pliku:

# ~/.codex/config.toml: wewnątrz tabeli [mcp_servers.terraform] utworzonej przez polecenie
env_vars = ["TFE_TOKEN", "TFE_ADDRESS"]

Dla HCP Terraform wyeksportuj TFE_ADDRESS=https://app.terraform.io przed uruchomieniem Codeksa.

// .cursor/mcp.json — tylko rejestr, bez tokena
{ "mcpServers": { "terraform": {
  "command": "docker",
  "args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server:1.3.0"] } } }

Dla HCP Terraform dodaj do args "-e", "TFE_TOKEN", "-e", "TFE_ADDRESS" przed nazwą obrazu, a po niej "--toolsets=registry,terraform" (albo --tools=, jak niżej). Samo -e NAZWA każe Dockerowi skopiować zmienną ze środowiska, z którego startuje Cursor, więc wyeksportuj tam obie i wywołaniem whoami sprawdź, że token dotarł. Nigdy nie wklejaj tokena do pliku.

Daj tokenowi najmniejszy dostęp, który wystarcza. W HCP Terraform token zespołu, który ma uprawnienie Plan do właściwych workspace’ów, może kolejkować plany i czytać przebiegi, ale nie może wykonać apply. Po konfiguracji poproś agenta raz o wywołanie whoami i get_token_permissions; odpowiedź to twój zapis audytowy tego, co agent może zrobić.

Nie instaluj w tej samej sesji terraform@claude-plugins-official. Rejestruje drugi serwer terraform przypięty do hashicorp/terraform-mcp-server:0.4.0, podczas gdy obraz jest w wersji 1.3.0.

Dodaj skille HashiCorp, żeby kod był dobrze napisany

Serwer MCP mówi agentowi, jak wygląda aktualne API. Skille HashiCorp mówią mu, jak HashiCorp chce, żeby pisać Terraform: terraform-style-guide (układ plików, nazewnictwo, for_each zamiast count), terraform-test, refactor-module, terraform-search-import, terraform-stacks, terraform-policy, azure-verified-modules i dziewięć skilli do tworzenia providerów.

claude plugin marketplace add hashicorp/agent-skills
claude plugin install terraform@hashicorp

# Repozytorium zawiera też .agents/plugins/marketplace.json o nazwie "hashicorp"
codex plugin marketplace add hashicorp/agent-skills
codex plugin add terraform@hashicorp

# Po jednym skillu przez CLI skills; ścieżka pochodzi z SKILLS.md w repozytorium
npx skills add hashicorp/agent-skills/plugins/terraform/skills/terraform-style-guide
npx skills add hashicorp/agent-skills/plugins/terraform/skills/terraform-test

Pomiar poleceniem claude plugin details terraform@hashicorp (wtyczka 1.0.0, 2026-09-26): 16 skilli, brak serwera MCP, ok. 2153 tokeny stale obecne w każdej sesji. Każdy skill kosztuje więcej, gdy zostanie użyty: ok. 2,6 tys. tokenów terraform-style-guide, 4,1 tys. terraform-test, 5,6 tys. refactor-module i 6,8 tys. provider-resources. Jeśli twój zespół pisze moduły, a nie providery, zainstaluj zamiast pakietu dwa pojedyncze skille z przykładu wyżej; siedem skilli provider-* stanowi większość stałego kosztu.

Przeprowadź zmianę infrastruktury: rejestr, moduł, plan, przegląd

Przykład: dodajesz regułę cyklu życia S3, która po 30 dniach przenosi obiekty do klasy Infrequent Access, w repozytorium, którego workspace w HCP Terraform jest podłączony do systemu kontroli wersji. Agent sprawdza i pisze, HCP Terraform tworzy plan, a apply zatwierdza człowiek.

Sprawdź aktualne API, zanim cokolwiek powstanie. Tu zestaw registry pokazuje, po co jest.

Use the terraform MCP server. Get the latest version of the hashicorp/aws provider and the version pinned in versions.tf.
Then get the provider docs for aws_s3_bucket_lifecycle_configuration at the pinned version and list the arguments I need for: a rule that transitions all objects to STANDARD_IA after 30 days and expires noncurrent versions after 90 days.
If the pinned and latest versions differ in those arguments, show the difference. Do not write any code yet.

Napisz zmianę jako moduł, z testami. Jeśli masz zainstalowane skille HashiCorp, wymień je z nazwy, żeby agent je załadował, zamiast improwizować.

Using the terraform-style-guide and terraform-test skills, add the lifecycle rule to modules/storage as a new variable-driven block (default: 30 days to STANDARD_IA, 90 days noncurrent expiry), wire it in envs/staging, and write a terraform test in modules/storage/tests/ that asserts the transition days and storage class from a plan.
Run terraform fmt -check, terraform validate and terraform test, and fix until all three pass. Do not run terraform apply.

Zrób plan w HCP Terraform. Wypchnij gałąź i otwórz pull request. Workspace podłączony do VCS uruchamia dla pull requesta plan spekulatywny. W workspace’ie sterowanym z CLI uruchom terraform plan z blokiem cloud. W obu przypadkach plan tworzy HCP Terraform ze swoimi zmiennymi, poświadczeniami i zestawami polityk.

Przejrzyj plan jako dane. Poproś agenta, żeby odczytał plan przez serwer MCP i sprowadził go do tego, o czym musi zdecydować recenzent.

Use the terraform MCP server. In organization acme, workspace storage-staging, find the latest run for this branch's pull request with list_runs, then read it with get_plan_json_output.
From resource_changes, count create, update, delete and replace actions. List every delete or replace with its address and the attribute that forces it.
Confirm the only changed resource is the lifecycle configuration in module.storage. Paste this summary into the pull request as a comment. Do not create, apply or discard any run.

apply wykonuje człowiek. Recenzent porównuje podsumowanie ze stroną planu, scala zmianę i zatwierdza apply w HCP Terraform. Gdy ENABLE_TF_OPERATIONS nie jest ustawione, agent nie ma narzędzia do apply, a jego token z uprawnieniem Plan i tak nie mógłby go wykonać.

Pętla jest taka sama w każdym agencie. Różni się tylko sposób, w jaki trzymasz ją w trybie tylko do odczytu:

Krok 1 uruchom w trybie planowania (plan mode); zatwierdź plan, a przed krokiem 2 wyjdź z trybu planowania. Filtruj na serwerze: usuń wcześniejszy wpis i dodaj go ponownie, zastępując --toolsets=registry,terraform flagą --tools= z dwunastoma narzędziami do odczytu. Serwer nie rejestruje wtedy nic więcej, więc nie zostaje żadne narzędzie zapisu do blokowania. Ten przełącznik działa tak samo we wszystkich trzech klientach.

claude mcp remove terraform -s project
claude mcp add terraform -s project \
  -e 'TFE_TOKEN=${TFE_TOKEN}' -e 'TFE_ADDRESS=${TFE_ADDRESS:-https://app.terraform.io}' \
  -- docker run -i --rm -e TFE_TOKEN -e TFE_ADDRESS hashicorp/terraform-mcp-server:1.3.0 \
  --tools=search_providers,get_provider_details,get_latest_provider_version,search_modules,get_module_details,list_workspaces,list_runs,get_run_details,get_plan_logs,get_plan_json_output,whoami,get_token_permissions

Użyj tego samego przełącznika serwera --tools= co w zakładce Claude Code albo filtruj po stronie klienta listą dozwolonych; Codex udostępnia modelowi tylko wymienione narzędzia. Dopisz klucz wewnątrz istniejącej tabeli [mcp_servers.terraform], nad ewentualną podtabelą [mcp_servers.terraform.env] (drugi nagłówek [mcp_servers.terraform] to niepoprawny TOML):

enabled_tools = ["search_providers", "get_provider_details", "get_latest_provider_version",
  "search_modules", "get_module_details", "list_workspaces", "list_runs",
  "get_run_details", "get_plan_logs", "get_plan_json_output", "whoami", "get_token_permissions"]

Filtruj na serwerze, jak w zakładce Claude Code: zastąp w args --toolsets=… flagą --tools= z tymi samymi dwunastoma narzędziami (serwer odrzuca obie flagi naraz). Krok 1 wykonaj w trybie planowania (Plan Mode); zatwierdź plan, przed krokiem 2 wyjdź z Plan Mode i przejrzyj diff, zanim go zaakceptujesz.

Uruchom serwery za bramką Docker MCP Toolkit

Bramka Docker MCP uruchamia każdy serwer z katalogu w osobnym kontenerze i przedstawia je klientom jako jeden serwer. Trzyma sekrety w systemowym pęku kluczy zamiast w zmiennych środowiskowych, domyślnie weryfikuje podpisy obrazów Dockera z przestrzeni mcp/, domyślnie blokuje sekrety w ruchu narzędzi (--block-secrets) i loguje wywołania narzędzi (--log-calls). Opłaca się, gdy kilka klientów korzysta z kilku serwerów SaaS.

# Terminal. Docker Desktop 4.59+ zawiera wtyczkę; w Docker CE uruchom: docker mcp feature enable profiles
docker mcp catalog pull mcp/docker-mcp-catalog
docker mcp profile create --name dev-tools \
  --server catalog://mcp/docker-mcp-catalog/github-official \
  --server catalog://mcp/docker-mcp-catalog/terraform
docker mcp oauth authorize github                               # albo zapisz token ze stdin:
printf '%s' "$GITHUB_PAT" | docker mcp secret set github.personal_access_token
docker mcp profile tools dev-tools --disable-all github-official
docker mcp profile tools dev-tools --enable github-official.list_issues --enable github-official.pull_request_read
docker mcp gateway run --profile dev-tools --dry-run             # sprawdza profil bez nasłuchiwania

Klientów podłączasz poleceniem docker mcp client connect <client> --profile dev-tools. Dokumentacja polecenia na gałęzi main wymienia wśród obsługiwanych klientów claude-code, codex i cursor (odczyt 2026-09-26); starsze wydania mogą nie mieć codex, więc sprawdź docker mcp client ls. Dodaj --global, jeśli wpis ma działać we wszystkich twoich projektach, a nie tylko w bieżącym repozytorium. Listy dozwolonych narzędzi w profilu nazywają narzędzia <server>.<tool>; zanim na którejś oprzesz się, sprawdź poleceniem docker mcp tools ls, co profil naprawdę udostępnia.

Trzy wpisy w katalogu nie są tym, co sugerują ich nazwy (sprawdzone w docker/mcp-registry, 2026-09-26):

github w katalogu Dockera to zarchiwizowany serwer referencyjny. Ma tytuł „GitHub (Archived)”. Używaj github-official, który uruchamia ghcr.io/github/github-mcp-server, choć przykład w README bramki wciąż podaje github.
kubernetes w katalogu Dockera to inny serwer. Uruchamia mcp/kubernetes, zbudowany z Flux159/mcp-server-kubernetes, i montuje wskazany przez ciebie kubeconfig. Wskaż mu domyślny ~/.kube/config, a dostanie twój kontekst administratora. Zostaw Kubernetesa jako bezpośredni wpis tylko do odczytu opisany wyżej albo daj wpisowi z katalogu kubeconfig mcp-viewer.
terraform w katalogu Dockera nie deklaruje sekretów. Przez bramkę dostajesz więc tylko narzędzia publicznego rejestru. Dla HCP Terraform zostaw bezpośredni wpis Dockera z TFE_TOKEN.

Dopuszczanie bramki w całej organizacji opisuje strona rejestry i bramki MCP.

Ile kontekstu kosztują serwery infrastruktury?

Schemat każdego zarejestrowanego narzędzia siedzi w kontekście każdej sesji. Zmierz, zanim ustandaryzujesz:

Instalacja	Co się ładuje	Stały koszt
Wtyczka `terraform@hashicorp` 1.0.0	16 skilli	ok. 2153 tokeny (zmierzone, `claude plugin details`)
Terraform MCP, bez tokena	9 narzędzi `registry`	uruchom `/context` przed i po `claude mcp add`
Terraform MCP, token, bez `--toolsets`	56 narzędzi (61 z `ENABLE_TF_OPERATIONS=true`)	unikaj; zawsze podawaj `--toolsets` lub `--tools`
Terraform MCP, `--toolsets=registry,terraform`	52 narzędzia (57 z `ENABLE_TF_OPERATIONS=true`)	52 schematy narzędzi zamiast 9; zmierz przez `/context`
Terraform MCP, `--tools=` z 12 narzędziami do odczytu	12 narzędzi	lista dozwolonych z pętli powyżej
Kubernetes MCP, `core` i `config`	23 narzędzia, mniej przy `read_only = true`	zmierz przez `/context`

Liczby narzędzi pochodzą z rejestrów narzędzi samych serwerów z 2026-09-26. Przycinaj najpierw przełącznikiem serwera (--tools w Terraformie, enabled_tools lub disabled_tools w TOML Kubernetesa), bo działa w każdym kliencie. Więcej technik znajdziesz w artykule o ograniczaniu kosztu tokenów MCP.

Jak zweryfikować pracę agenta przy infrastrukturze?

Sprawdzasz dowody, a nie relację agenta:

Granicą jest tożsamość. kubectl auth can-i pokazuje, co może konto mcp-viewer, a get_token_permissions, co może token Terraforma. Obie odpowiedzi trafiają raz do pull requesta, przy przeglądzie konfiguracji.
Każda diagnoza cytuje swoje odczyty. Raport o CrashLoopBackOff przytacza powód wyjścia, linie logów i zdarzenie, na których się oparł. Recenzent porównuje trzy fakty z kubectl describe pod, a nie rozumowanie.
Kontrole jakości działają przed planem. terraform fmt -check, terraform validate i terraform test przechodzą lokalnie i ponownie w CI; manifesty przechodzą walidację w twoim CI.
Artefaktem przeglądu jest plan. Recenzent czyta liczby akcji create, update, delete i replace oraz każde delete i replace, porównując je ze stroną planu w HCP Terraform. Każde nieoczekiwane delete lub replace blokuje scalenie.
apply i rollback wykonuje człowiek. apply zatwierdza w HCP Terraform właściciel workspace’u; zmiany w Kubernetesie wychodzą przez pipeline wdrożeniowy. Rollback to ta sama droga w drugą stronę: revert commita albo kubectl rollout undo uruchomione przez osobę z uprawnieniami zapisu.
Kontrola akceptacyjna działa po wdrożeniu. Dla poprawki poda: zero restartów przez 15 minut i wszystkie repliki w stanie Ready; dla zmiany w Terraformie: reguła cyklu życia widoczna na buckecie.

Co się psuje w serwerach MCP dla infrastruktury?

Serwer Kubernetesa wczoraj się łączył, a dziś nie. Token ServiceAccount z kubectl create token wygasł. Wydaj nowy i powtórz linię set-credentials; nic więcej się nie zmienia. Krótki czas życia tokena jest celowy.

Agent nadal widzi pods_delete. Plik TOML nie został wczytany albo klucz ma literówkę. Sprawdź ścieżkę --config we wpisie, to, czy Claude Code rozwinął ${HOME} (uruchom claude mcp get kubernetes), i czy klucz brzmi dokładnie read_only = true na najwyższym poziomie pliku, a nie pod nagłówkiem tabeli.

pods_log nie zwraca nic przydatnego dla padającego poda. Bieżący kontener dopiero wystartował. Poproś o previous: true, co zwraca logi zakończonego kontenera, czyli te z awarią.

Brakuje zdarzeń. Kubernetes przechowuje zdarzenia przez ograniczony czas, więc po starej awarii nic nie zostało. Oprzyj się na logach poprzedniego kontenera i różnicy między ReplicaSetami, a lukę odnotuj w raporcie.

Brakuje narzędzi Terraforma wymagających tokena. TFE_TOKEN nie dotarł do kontenera. docker run -e TFE_TOKEN przekazuje zmienną tylko wtedy, gdy ma ją proces Dockera: w Claude Code sprawdź blok env w .mcp.json, w Codeksie env_vars, i wyeksportuj zmienną przed uruchomieniem agenta.

Codex nie startuje po edycji config.toml. Błąd brzmi invalid type: sequence, expected a string in mcp_servers.<name>.env.env_vars. Dopisałeś env_vars albo enabled_tools na końcu pliku i klucz trafił do podtabeli [mcp_servers.<name>.env], którą tworzy codex mcp add --env. Przenieś tę linię wyżej, do samej tabeli [mcp_servers.<name>], i potwierdź poleceniem codex mcp get <name> --json (sprawdzone w codex-cli 0.157.1).

Agent pisze argumenty, które odrzuca terraform validate. Pominął sprawdzenie w rejestrze albo przeczytał najnowszą dokumentację, choć provider jest przypięty do starszej wersji. Zrób z kroku 1 osobną turę i podaj w prompcie przypiętą wersję.

Dwa serwery terraform i stare nazwy narzędzi. Zarejestrowane są jednocześnie oficjalna wtyczka Claude (obraz 0.4.0) i twój wpis. Zostaw jeden: claude plugin uninstall terraform@claude-plugins-official albo usuń swój wpis.

Agent wykonuje polecenia z tekstu w logu lub planie. Logi podów, zdarzenia i wyniki planu mogą zawierać ciągi kontrolowane przez atakującego, które trafiają do modelu jako dane, za którymi może pójść. Tożsamości tylko do odczytu ograniczają szkody; nie trzymaj też w tej samej sesji innych serwerów z prawem zapisu i przeczytaj o bezpieczeństwie MCP, zanim podłączysz klaster produkcyjny.

Problemy z połączeniem w ogóle opisuje strona problemy z połączeniem serwerów MCP.

@kubernetes/mcp-server, @docker/mcp-gateway, @docker/hub-mcp, @hashicorp/terraform-mcp-server: nie ma ich w npm. Prawdziwe nazwy to kubernetes-mcp-server (npm i PyPI), wtyczka CLI docker mcp i obraz Dockera hashicorp/terraform-mcp-server.
npm docker-mcp: pakiet społeczności, nie Dockera.
kubernetes-mcp-server --read-only albo --toolsets: działa w 0.0.67, ale na gałęzi main jest wycofywane i przestanie działać po 0.0.67. Ustawienia trzymaj w pliku TOML.
mcp-server-kubernetes (Flux159, npm 4.1.7) to inny serwer, z innymi narzędziami i ustawieniami; to on stoi za wpisem kubernetes w katalogu Dockera.
ENABLE_TF_OPERATIONS=true, „żeby agent mógł planować”: planowanie działa bez tego. Zmienna włącza apply, discard, cancel, force-unlock i usuwanie workspace’ów, projektów i zespołów. Nie jest jedyną ochroną: delete_variable_in_variable_set i detach_variable_set_from_workspaces rejestrują się bez niej, a przebieg refresh_state lub allow_empty_apply w workspace’ie z auto-apply może wykonać apply. Prawdziwą granicą jest uprawnienie Plan tokena.
terraform@claude-plugins-official a terraform@hashicorp: pierwsza to serwer MCP przypięty do obrazu 0.4.0; druga to skille HashiCorp i nie zawiera serwera.

Dokąd dalej z MCP dla infrastruktury

Wzorce dla Kubernetesa Przepisy na manifesty, wdrożenia i debugowanie, które pasują do serwera tylko do odczytu z tej strony.

Infrastruktura jako kod z agentami Szerszy przepływ IaC: układ repozytorium, plany w CI i dryf, poza tym, co czyta serwer MCP.

Docker i Kubernetes z agentami Pisanie Dockerfile’i, manifestów i chartów Helma, które potem sprawdzają serwery z tej strony.

Serwery MCP platform chmurowych Serwery AWS, Azure i Google Cloud dla zasobów, którymi zarządza twój Terraform.

MCP do obserwowalności Połącz stan klastra z dowodami z Sentry, Grafany i Datadoga w pętli incydentu.