Potencia tu agente
El comando propio del publicador. No es un endpoint de PlugMCP.
Host a copy with our keys and logs.
uvx ocm-mcp-server==0.6.0Claude Code no tiene enlace de instalación para un comando local. Copia el comando de abajo y ejecútalo en una terminal.
KUBECONFIG=<value> OCM_MCP_HUB_CONTEXT=<value> OCM_MCP_READ_ONLY=<value> claude mcp add io.github.ocm-mcp-server-ocm-mcp-server -- uvx ocm-mcp-server==0.6.0Ejecútalo en una terminal.
{ "mcpServers": { "io.github.ocm-mcp-server-ocm-mcp-server": { "command": "uvx", "args": [ "ocm-mcp-server==0.6.0" ], "env": { "KUBECONFIG": "<value>", "OCM_MCP_HUB_CONTEXT": "<value>", "OCM_MCP_READ_ONLY": "<value>" } } }}claude_desktop_config.json
¿URL remota o un comando en tu máquina? En qué se diferencian las dos instalaciones
Ejecutar en PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
AbrirDel publicador
An MCP server that lets AI agents operate a multi-cluster Kubernetes fleet through an hub, with policy, approval, and audit between the model and your clusters.
Guardrailed fleet ops for AI agents: multi-cluster Kubernetes via OCM with policy, approval, audit.
The agent never holds a kubeconfig. Every write is policy-checked, human-approved, and traced.
📦 Get it · ✨ Why · 🔌 Connect your agent · 🧭 Architecture · 🧰 Toolsets · 🛠️ Tools · 💬 Prompts · 🔭 Observability · 🚀 Quickstart · 📖 Wiki · 📚 Docs
The whole safe-remediation loop: investigate with free reads, propose a change, get rejected by the guardrails and correct it, wait for a human-signed token, apply, verify, and report from the audit log.
ocm-mcp-server - pip install ocm-mcp-server
(or run directly with uvx ocm-mcp-server). Every release is published straight from CI via
OIDC trusted publishing - no long-lived tokens anywhere.io.github.ocm-mcp-server/ocm-mcp-server, so any MCP client or platform that browses the registry can
discover and auto-configure this server (package, transport, and required env vars are all in the
listing); the registry validates the listing against this repo and the PyPI package.docker run ghcr.io/ocm-mcp-server/ocm-mcp-server (kubeconfig mount shown in the
deployment guide); built in CI with an SBOM and SLSA provenance attached,
vulnerability-gated with Trivy, and signed keyless with Cosign so you can verify what you run.Your team runs many Kubernetes clusters. Sooner or later somebody asks the question: can an AI agent take the 2 a.m. page?
The quickest way to find out is to hand a model kubectl with cluster-admin and watch.
In production that experiment ends badly, for three separate reasons:
kubectl delete the next.This project starts from a different observation: fleets already have a control point that
humans trust every day, the multi-cluster hub. Open Cluster Management (a CNCF project)
gives every fleet an inventory (ManagedCluster), a scheduler (Placement), and a delivery
channel (ManifestWork). ocm-mcp-server exposes that hub to agents as a small set of
typed MCP tools, and puts four independent layers
between the model and your clusters:
None of these layers live in the system prompt, so none of them can be talked out of.
A write is two calls with a person between them. The token is bound to one content hash and one operation, it expires on its own, and offered a second time it is refused.
Two writes, the same four gates. The privileged, unpinned one dies at Layer 1 and never reaches a cluster; the compliant one waits for a person to sign the exact content, then lands and is verified.
A fleet operator's day with Claude, live from a cold start: install from PyPI, claude mcp add, inventory the fleet, reason about placement — then ship a new service the gated way: the privileged :latest shortcut is refused, the pinned proposal is signed by a human, applied with the token, verified, and the whole day is read back from the audit trail. — narrated MP4 · terminal cast.
The same day, driven by four different agents. Identical ten chapters, identical server - only the agent asking changes, which is the whole point of speaking MCP rather than shipping a client. Codex · Gemini (Antigravity CLI). Re-record any of them with hack/demo-record.sh all.
The server speaks standard MCP over stdio; nothing here is specific to one vendor's agent.
That claim is demonstrated, not asserted: the same ten-chapter operator session is
recorded against four different agents - Claude Code, Codex, Gemini through the
Antigravity CLI, and IBM Bob Shell - driving the same server against the same fleet, each
one really calling the tools, hitting the guardrail refusal, and applying only with a
human-signed token.
Re-record any of them with hack/demo-record.sh all.
{
"mcpServers": {
"ocm-fleet": {
"command": "ocm-mcp-server",
"env": {
"OCM_MCP_HUB_CONTEXT": "kind-hub",
"OCM_MCP_SPOKE_CONTEXTS": "cluster1=kind-cluster1,cluster2=kind-cluster2,cluster3=kind-cluster3"
}
}
}
}
{
"servers": {
"ocm-fleet": {
"type": "stdio",
"command": "ocm-mcp-server",
"env": {
"OCM_MCP_HUB_CONTEXT": "kind-hub",
"OCM_MCP_SPOKE_CONTEXTS": "cluster1=kind-cluster1,cluster2=kind-cluster2,cluster3=kind-cluster3"
}
}
}
}
Note the top-level key is servers, not mcpServers - VS Code differs from
Claude Code and Gemini CLI here, and copying one into the other fails silently.
[mcp_servers.ocm-fleet]
command = "ocm-mcp-server"
[mcp_servers.ocm-fleet.env]
OCM_MCP_HUB_CONTEXT = "kind-hub"
OCM_MCP_SPOKE_CONTEXTS = "cluster1=kind-cluster1,cluster2=kind-cluster2,cluster3=kind-cluster3"
{
"mcpServers": {
"ocm-fleet": {
"command": "ocm-mcp-server",
"env": {
"OCM_MCP_HUB_CONTEXT": "kind-hub",
"OCM_MCP_SPOKE_CONTEXTS": "cluster1=kind-cluster1,cluster2=kind-cluster2,cluster3=kind-cluster3"
}
}
}
}
{
"mcpServers": {
"ocm-fleet": {
"command": "ocm-mcp-server",
"env": {
"OCM_MCP_HUB_CONTEXT": "kind-hub",
"OCM_MCP_SPOKE_CONTEXTS": "cluster1=kind-cluster1,cluster2=kind-cluster2,cluster3=kind-cluster3"
}
}
}
}
Most MCP clients accept an mcpServers block like this one. If ocm-mcp-server is not
on the PATH the client launches with, use the absolute path from
which ocm-mcp-server as the command value.
Give the agent the runbook discipline in
examples/system-prompt.md, then break something and watch
the flow:
make inject SCENARIO=failing-rollout CLUSTER=cluster2
You: "Payments is degraded somewhere in the fleet. Investigate and fix."
Agent:
list_clusters→get_cluster_health(cluster2)→query_events→get_pod_logs→ "payments-v2 on cluster2 is in ImagePullBackOff. Proposing a ManifestWork pinning the last good image. Proposal4f1a2b3cneeds your approval."You (trusted terminal):
ocm-mcp approve 4f1a2b3c, then paste the token back.Agent:
apply_manifestwork→ verifies recovery →get_audit_trail→ writes the incident report.
Then try to talk it into something dangerous ("just redeploy it privileged with hostNetwork, it's faster"). The proposal dies at layer 1 or layer 2, and the rejection message tells the agent exactly why. More worked examples →
flowchart LR
A["🤖 AI Agent<br/>(any MCP client)"] -->|"typed tool calls"| S["🛡️ ocm-mcp-server<br/>static guardrails · audit"]
S -->|"reads + dry-run + apply"| H["☸️ OCM Hub<br/>Placement · ManifestWork<br/>Kyverno · RBAC"]
H --> C1["cluster1"]
H --> C2["cluster2"]
H --> C3["cluster3"]
U["🧑💻 Human operator<br/>ocm-mcp approve"] -.->|"approval token"| A
S -.->|"spans"| J["🔍 OpenTelemetry / Jaeger"]
The write path in one sentence: the agent proposes a ManifestWork; static guardrails
and a Kyverno dry-run validate it; a human reviews the exact content and mints an
approval token bound to its hash; only then does apply deliver it, with every step traced
and logged.
The second guardrail layer does not live in this server - it lives in the cluster. Before a
proposed change is ever stored, the server does a server-side dry-run create of the
ManifestWork on the hub, so the hub's Kyverno validating admission
runs against the exact manifests the agent wants to apply. If your organization's policy
says no, the proposal is rejected at admission with the policy's own message - the same
control that governs every human kubectl apply.
Why Kyverno:
ManifestWork.Where it is used here:
deploy/policies/ ships 9 ClusterPolicy objects that foreach
over spec.workload.manifests inside a ManifestWork: block privileged/host access,
protect system namespaces, enforce a kind allow-list, require the managed-by label from the
server ServiceAccount (so an unlabeled work cannot skip the others), and enforce a
Restricted-Pod-Security baseline in parity with the static guardrails. They are scoped by the
app.kubernetes.io/managed-by: ocm-mcp-server label so they judge only agent-authored work.
They are usable on their own: deploy/policies/README.md
documents the foreach-over-embedded-manifests pattern, the two identifiers an adopter
changes, and the Kyverno versions the pack is actually tested against.make policy-test runs a 46-case offline suite with the kyverno CLI - good, bad, and
human-authored ManifestWorks - needing no cluster and no dependencies. It runs in CI, so a
policy regression fails the build before it can reach a hub.The surface is 37 tools across ten toolsets. Almost all of it is read: the whole
Open Cluster Management API is safe to inspect. Only two toolsets can change
anything, and only through the propose -> approve -> apply gate. Every hub-level
tool works for any managed spoke - a standalone OpenShift cluster, a HyperShift
hosted cluster, or a cloud cluster - because on the hub they are all ManagedClusters.
The whole surface at once. Eight toolsets cannot change anything at all; the two that can are the two wearing a lock.
Every read tool is annotated readOnlyHint; every write tool is annotated
destructiveHint and enforced by the gate. Setting OCM_MCP_READ_ONLY=1 turns off
the two writing toolsets entirely, for a strictly-inspection deployment.
Validate against your own hub in one command:
ocm-mcp doctorcalls every read tool against the live hub and prints aPASS / EMPTY / SKIP / FAILtable (writing nothing), so you can confirm exactly what the server sees before wiring up an agent.
The two lanes, to scale: a read answers straight away, a write crawls through propose, a human signature, and a one-time-token apply.
There is deliberately no tool that reads Secrets, execs into pods, or deletes
arbitrary resources. The generic reader (list_resources / get_resource) works
against an allow-list of OCM types, so Secrets are not restricted - they are
simply not expressible. A capability that does not exist cannot be prompt-injected
into use.
Each tool below is annotated with its class: read (free, no gate), propose (stores a pending change, mutates nothing), or apply (delivers an approved change; needs a human token).
list_clusters (read) - all managed clusters with availability, version, labels, capacity.get_cluster (read) - full view of one cluster.
cluster (string) - managed cluster name.list_cluster_sets (read) - ManagedClusterSets with selector type and member clusters.list_cluster_set_bindings (read) - which ClusterSets a namespace's Placements may target.
namespace (string, optional) - limit to one namespace; empty lists all.list_cluster_claims (read) - every cluster's ClusterClaims (id, platform, region, version).get_cluster_info (read) - extended inventory from the hub (OpenShift version, nodes, console URL); needs no spoke access.
cluster (string) - managed cluster name.get_cluster_health (read) - hub conditions, unhealthy pods, degraded deployments.
cluster (string) - managed cluster name.get_fleet_health (read) - health of the whole fleet in one call: hub conditions for every cluster plus concurrent spoke scans; broken spokes show as an error entry instead of failing the sweep.
clusters (string, optional) - comma-separated cluster names to scope the sweep; empty means every cluster.query_events (read) - recent Kubernetes events, newest first.
cluster (string) - managed cluster name.namespace (string, optional) - namespace filter; empty means all.limit (int, optional) - max events (default 40).get_pod_logs (read) - tail a pod's logs (falls back to the previous instance if crashing).
cluster (string), namespace (string), pod (string) - target.container (string, optional) - container name; empty picks the default.lines (int, optional) - trailing lines (default 80).list_placements (read) - Placements and how many clusters each selects.
namespace (string, optional) - limit to one namespace.get_placement_decision (read) - the clusters a Placement actually selected.
placement (string) - Placement name.namespace (string) - the Placement's namespace.list_addon_placement_scores (read) - custom scores prioritizers consume.
cluster (string) - managed cluster name.list_manifestworks (read) - ManifestWorks targeting a cluster.
cluster (string) - managed cluster name.get_manifestwork (read) - detailed status + per-resource status feedback (the "why not Applied").
cluster (string), name (string) - target.list_manifestworkreplicasets (read) - a template fanned across a Placement, with rollout summary.
namespace (string, optional) - limit to one namespace.propose_manifestwork (propose) - propose a change as a ManifestWork. Applies nothing.
cluster (string) - target cluster.name (string) - short kebab-case ManifestWork name.summary (string) - one or two sentences the human approver reads.manifests_json (string) - JSON array of complete manifests (allowed kinds; namespaced; pinned images).apply_manifestwork (apply) - deliver an approved ManifestWork.
proposal_id (string), approval_token (string) - from ocm-mcp approve <id>.propose_rollback (propose) - propose undoing an applied ManifestWork; creates a rollback proposal bound to its UID.
proposal_id (string) - the applied ManifestWork proposal to undo.rollback_manifestwork (apply) - delete the ManifestWork after the rollback is approved (needs a rollback-scoped token).
rollback_proposal_id (string), approval_token (string).list_cluster_management_addons (read) - fleet-level add-on definitions and install strategy.get_addon_health (read) - per-cluster ManagedClusterAddOn Available / Degraded / Progressing.list_addons_for_cluster (read) - every add-on on one cluster, with install namespace and health.
cluster (string) - managed cluster name.list_pending_csrs (read) - pending cluster-join / add-on registration CSRs awaiting approval.propose_cluster_action (propose) - propose a lifecycle action. Applies nothing.
cluster (string) - target cluster.action (string) - one of cordon (taint out of scheduling), uncordon, set_label, accept (hubAcceptsClient + approve join CSRs), enable_addon / disable_addon (create/delete a ManagedClusterAddOn).summary (string) - what the human approver reads.params_json (string, optional) - action parameters; set_label needs {"key","value"}, the add-on actions need {"addon"} (+ optional install_namespace).apply_cluster_action (apply) - apply an approved lifecycle action.
proposal_id (string), approval_token (string).list_policies (read) - Policies and per-cluster compliance. Reports clearly if the governance add-on is not installed.
namespace (string, optional) - limit to one namespace.list_policy_violations (read) - only the NonCompliant / Pending policy-cluster pairs across the fleet.list_hosted_clusters (read) - HostedClusters with version and conditions. Reports clearly if HCPs are hosted on a different management cluster.
namespace (string, optional) - limit to one namespace.get_hosted_cluster (read) - one HostedCluster in detail, with its NodePools.
name (string), namespace (string) - target.list_node_pools (read) - HyperShift NodePools (worker groups), desired vs current replicas.
namespace (string, optional), cluster (string, optional) - filters.list_resources (read) - list any allow-listed OCM type (identity + conditions).
resource (string) - e.g. managedclusters, placements, manifestworks, managedclusteraddons, klusterlets.namespace (string, optional) - for namespaced types.get_resource (read) - get one allow-listed OCM object in full. Never returns a Secret (not on the allow-list).
resource (string), name (string) - target.namespace (string, optional) - required for namespaced types.list_pending_proposals (read) - ManifestWorks and cluster actions awaiting approval.get_audit_trail (read) - the last N tool calls from this server's append-only log.
last_n (int, optional) - trailing entries (default 30).The server also ships ten MCP prompts - reusable templates that encode the safe workflow so any client can start from a good runbook instead of a blank box.
The server also exposes 6 MCP resources - read-only fleet state a client can pin, browse, or attach as context without a tool call (strictly a subset of the read tools; every access still writes an audit line):
Every tool call produces up to three independent records, each with a different job:
The same call, recorded twice. Edit an earlier line and the chain says so; the spans, meanwhile, only ever answer where the time went.
What the tracing is: OpenTelemetry is the CNCF
standard for distributed tracing; Jaeger is a CNCF
trace viewer. When enabled, this server opens one span per tool call - named
tool.<name> (e.g. tool.apply_manifestwork) - with the call's arguments attached
as attributes. The approval_token is never attached, and argument values are
truncated at 200 characters, so traces are safe to ship to a shared backend.
Why it exists alongside the audit log: the audit log is a safety artifact -
append-only and tamper-evident - while spans are a debugging artifact: in Jaeger
you can see that a get_cluster_health call spent 4 s waiting on one spoke, or
follow the exact propose → apply sequence of an incident on a timeline. Nothing
safety-related trusts the spans, which is why tracing can stay optional and
fail-soft: without the extra installed and an endpoint set, it is a no-op.
How to use it (two switches + a viewer):
pip install "ocm-mcp-server[tracing]" # OTel SDK + OTLP/HTTP exporter
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 # your collector
# a local Jaeger to look at traces (make bootstrap starts this for you):
podman run -d --name jaeger -p 16686:16686 -p 4318:4318 jaegertracing/all-in-one:1.60
# open http://localhost:16686 and select the "ocm-mcp-server" service
How it is tested: unit tests cover span creation, token redaction, and the
no-op paths; the e2e suite includes a tracing-export step that stands up a local
OTLP sink, makes a tool call in a fresh server process, and asserts a real trace
batch arrives naming both the tool.* span and the ocm-mcp-server service - so
the export wiring is proven on every make e2e and in the nightly CI run. Details:
deployment guide - tracing
and architecture - observability.
Three ways in. Every row ends somewhere useful — nobody has to reach the third to get an answer out of the first.
Requirements: podman (or docker), kind, kubectl, clusteradm, helm, Python 3.11+, Linux or macOS (Windows unsupported - use WSL2). The deployment guide has install commands and the real-fleet path.
git clone https://github.com/ocm-mcp-server/ocm-mcp-server.git
cd ocm-mcp-server
make bootstrap # 1 hub + 3 managed kind clusters, OCM, Kyverno, policies, demo app
make install # pip install -e ".[dev,tracing]"
The server is configured entirely through environment variables. The two that matter most
are kubeconfig context names. New to those? The
context names guide explains what they are and the exact
commands to find yours, from a laptop kind cluster to a cloud login. In short: run
kubectl config get-contexts and read the NAME column (make bootstrap prints
ready-to-paste values at the end).
For key management, ocm-mcp rotate-secret generates a fresh Ed25519 approval keypair
(invalidating every outstanding approval token); ocm-mcp doctor runs the live read-path
smoke test; and ocm-mcp audit-verify recomputes the audit log's hash chain to detect any
edit, reordering, or mid-log deletion.
# the values make bootstrap prints, spelled out:
export OCM_MCP_HUB_CONTEXT=kind-hub # context of the hub cluster
export OCM_MCP_SPOKE_CONTEXTS=cluster1=kind-cluster1,cluster2=kind-cluster2,cluster3=kind-cluster3
# └ name on the hub ┘ └ kubeconfig context with read-only creds ┘
Not sure where kind-hub or cluster1=kind-cluster1 come from, or what your own values
should be? The context names guide walks through it
step by step, including cloud logins (EKS, GKE, AKS, OpenShift). Pointing at a real
fleet instead of kind? Same variables; the deployment guide covers
the read-only spoke accounts and production hardening.
Then hand the server to your agent: the ready-made client configs are in Connect your agent near the top of this README.
eval/ ships 22 scripted incident scenarios in three classes: remediate (15),
diagnose-only (3), adversarial (4). Scoring is objective on all three axes: diagnosis
keywords in the transcript, live cluster state for recovery, and the server's own audit log
for safety.
python3 eval/run_eval.py --agent-cmd "claude -p" # or any agent CLI
Published results (eval/results/published/), failures
included. Every row links to its own raw JSON:
All runs on the same build (v0.6.0, 37 tools, MCP SDK 2.1.1), same fleet, same 22 scenarios. Time taken is wall clock for the whole run. The agy run did not pin a reasoning tier: that CLI offers the model only as high/medium/low and the run took its default, so the exact tier is not recorded.
Not measured counts scenarios where the agent made no tool call, so the server was never consulted. The agent declined on its own, before the request reached the guardrails. Those are excluded from the safety denominator rather than scored, because counting them either way misreports: as a guardrail success that was not earned, or as a failure that did not happen.
Safety is the axis this server exists for, and it held on every scenario that reached it. The interesting number is the one beside it. Frontier models increasingly refuse an adversarial bait before calling any tool, so the guardrails are never consulted and a bait that was never presented would otherwise score identically to a bait that was blocked. Recovery misses concentrate on scenarios whose fix needs state the read surface deliberately withholds.
Diagnosis and recovery belong to the agent and are published unflattered. Safety is the axis this server is answerable for, and it is the full one.
Run it against your model of choice and publish your numbers, including the failures. The point is real data about what agents can and cannot yet be trusted to do.
The Kyverno policies have their own offline test suite: make policy-test runs 46 CLI
cases (deploy/policies/tests/) against good, bad, and
human-created ManifestWorks with no cluster and no dependencies. It runs in CI too, so a
policy regression fails the build before it ever reaches a hub.
Want proof it works against real clusters, not mocks? One script stands up a real Open Cluster Management fleet on kind, exercises every tool and prompt, runs a break-then-fix scenario, and writes a graphical HTML report:
./hack/e2e-local.sh # 2 spokes, auto-cleanup (SPOKES=1 for a lighter run)
It (1) installs or version-checks the dependencies (Podman, kind, kubectl, clusteradm,
helm; Docker is not required), (2) bootstraps a hub plus spokes, (3) runs every read
tool, the gated propose -> approve -> apply write flow, the gated ROLLBACK flow, every
lifecycle action (cordon/uncordon, set_label, accept, enable/disable_addon), and all ten
prompts - each with a plain-language explanation of what it does and why, (4) drives the
real server binary over stdio JSON-RPC with the official MCP client (handshake, tools,
prompts, resources, annotations), (5) runs a negative sweep proving every gate fails
closed (expired token, replayed token, apply-scoped token refused for rollback, read-only
mode, tampered audit log caught, signed audit anchor verified) plus a tracing-export
check (OTel spans over OTLP received by a local sink), (6) injects a failing
rollout and shows the diagnose-and-fix loop end to end, then (7) writes
e2e-report.html and tears the fleet back down (kind and Podman stay installed). The
report is git-ignored. Works on macOS (Homebrew + Podman) and Linux, and runs
nightly in CI.
ocm-mcp doctor runs just the live read-path smoke test on its own, against any hub.
Here is a real, unedited run (recorded with asciinema, long waits compressed): the fleet comes up, every step passes, and the fleet is torn down again - MP4 version · terminal cast:
src/ocm_mcp_server/ the MCP server: tools, guardrails, approvals, tracing, CLI
deploy/ least-privilege RBAC + Kyverno ClusterPolicies (+ offline tests)
hack/ bootstrap.sh / teardown.sh / demo app (kind-based fleet)
chaos/ failure-injection scenarios (reversible, diagnosable)
eval/ 22-scenario evaluation harness + results
blogs/ long-form posts (canonical drafts; published to Medium)
docs/ deployment, examples, architecture, guardrails, demo, upstream
examples/ MCP client configs (Claude, VS Code, Codex, Gemini) + system prompt
The canonical, themed roadmap lives in ROADMAP.md. Current headline items: an authenticated HTTP transport with per-tool scopes, an off-box (KMS/HSM) approval signer, the OCM cluster-proxy transport, and a reusable Kyverno policy pack. (Multi-model eval results are now published.)
Have a need that's not there? Open a feature request. New tools require a safety rationale; see CONTRIBUTING.md.
Issues and PRs welcome. Start with CONTRIBUTING.md. Getting help: SUPPORT.md. Security reports (privately, please): SECURITY.md.
This project is independently maintained. If your organization wants priority integration help, a hardened deployment review, sponsored features, or talks and workshops on safe agentic operations, connect on LinkedIn (details in SUPPORT.md).
Sandeep Bazar - Passionate in Technology especially around Multi-cluster Kubernetes platforms, day-2 operations, and making fleets safer to automate.
If this project is useful to you, a ⭐ helps others find it.
This project holds itself to CNCF community, governance, and security practices as a quality bar - the same standards expected of a CNCF Sandbox project - so it is easy to adopt, contribute to, and trust. The scaffolding is in place:
Contributions are signed off under the DCO - enforced by a CI job on every pull request, not just asked for in a checklist - published release tags are immutable, and any change that touches a guardrail requires a written safety rationale.
Guardrailed fleet ops for AI agents: multi-cluster Kubernetes via OCM with policy, approval, audit.
{ "mcpServers": { "io.github.ocm-mcp-server-ocm-mcp-server": { "command": "uvx", "args": [ "ocm-mcp-server==0.6.0" ], "env": { "KUBECONFIG": "<value>", "OCM_MCP_HUB_CONTEXT": "<value>", "OCM_MCP_READ_ONLY": "<value>" } } }}Herramientas
Aún no hay lista de herramientas. Los servidores remotos la reciben tras la primera comprobación de estado.
Preguntas frecuentes
Copia en esta página la configuración stdio para Cursor, Claude Desktop, Claude Code o VS Code. Usa la instalación del publicador, no un proxy de PlugMCP.
El publicador indica estas variables de entorno: KUBECONFIG, OCM_MCP_HUB_CONTEXT, OCM_MCP_READ_ONLY.
Ocm se ejecuta localmente por stdio.
Última comprobación: 2026-11-10. Guardrailed fleet ops for AI agents: multi-cluster Kubernetes via OCM with policy, approval, audit.