# kube-noob (pypi · kube-noob)

Kubernetes, OpenShift, ROSA HCP, Helm and RHACS audit, debugging and cited docs. No AI inside.

- Trust score: 62/100 (medium)
- Change this week: −3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- pypi · `kube-noob`: 62/100 (this document), [markdown](https://verifymcp.io/servers/aashishmahajan-kube-noob/kube-noob.md), [page](https://verifymcp.io/servers/aashishmahajan-kube-noob/kube-noob)

## Channel facts

- Registry: `pypi`
- Package: `kube-noob`
- Version: `0.7.1`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 50/100
  - Malware scan not yet available for this package.
  - No known CVEs affecting this package version or its production dependencies.
  - Runs hatchling.build at install time, a recognised build step with no custom scripting around it.
  - 1 of 32 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 74/100
  - Repository check failed: the declared repository URL redirects; it must resolve directly.
  - Cryptographically verified build provenance (signed, bound to aashishmahajan/kube-noob).
  - Clear OSI-approved license (Apache-2.0).
  - Actively maintained (last published 5 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 62/100
  - 67% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 6785 tokens (~138/item across 49 items; 47 tools + 2 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 30/100
  - Stability observed for 9 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 91/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 68% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 47 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 49 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the kube-noob MCP server?

kube-noob runs locally as a PyPI package, launched with uvx kube-noob. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add aashishmahajan-kube-noob -- uvx kube-noob
```

### Cursor

```json
{
  "mcpServers": {
    "aashishmahajan-kube-noob": {
      "command": "uvx",
      "args": [
        "kube-noob"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "aashishmahajan-kube-noob": {
      "command": "uvx",
      "args": [
        "kube-noob"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add aashishmahajan-kube-noob -- uvx kube-noob
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "aashishmahajan-kube-noob": {
      "type": "local",
      "command": [
        "uvx",
        "kube-noob"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add aashishmahajan-kube-noob --command uvx --arg kube-noob
```

### Hermes

```yaml
mcp_servers:
  aashishmahajan-kube-noob:
    command: "uvx"
    args: ["kube-noob"]
```

### Netclaw

```json
{
  "McpServers": {
    "aashishmahajan-kube-noob": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "kube-noob"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add aashishmahajan-kube-noob -t stdio -c uvx -a kube-noob
```

### Other

```json
{
  "mcpServers": {
    "aashishmahajan-kube-noob": {
      "command": "uvx",
      "args": [
        "kube-noob"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 62, −15)

- [security regression] Malware scan: pass → unverified

### 2026-11-04 (score 77, −5)

- [security regression] Source repository: pass → fail

### 2026-11-03 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-01 (score 81, +1)

- [functional improvement] Security disclosure: unverified → pass

### 2026-10-31 (score 80, +15)

- [security improvement] Malware scan: unverified → pass
- [functional regression] Security disclosure: pass → unverified
- [functional] Package version: 0.7.0 → 0.7.1

### 2026-10-30 (score 65, 0)

- [functional regression] Schema quality: 6105 → 6722
- [functional] Package version: 0.6.0 → 0.7.0

### 2026-10-29 (score 65, +1)

- [functional regression] Schema quality: pass → fail
- [functional improvement] Tool coverage: 57% → 67%
- [functional] Package version: 0.4.0 → 0.6.0

### 2026-10-28 (score 64, +1)

- [functional regression] Schema quality: 74 → 85
- [functional improvement] Stability: unverified → 0.03
- [functional] Schema quality: fair → good
- [functional] Package version: 0.3.0 → 0.4.0

## MCP tools (47)

### `kubenoob_run_protocol` (~122 tokens)

Run the 7-step engineering protocol

Clarify -> Validate -> Research -> Audit -> Calibrate -> Generate -> Red Team for a request with existing manifests or a generator blueprint. Returns the Audit & Validation Brief, the production manifest, and Red Team findings with safeguards. Use this first for any design/review request.

Input parameters:

- `apply_fixes` (boolean)
- `blueprint`: Generator blueprint (see generate_manifests).
- `manifests`: Existing manifests to review.
- `platform`
- `request` (string, required): What the user wants, in their words.
- `version`

### `kubenoob_validate_manifests` (~113 tokens)

Validate manifests

Strict schema validation (Kubernetes 1.35 + OpenShift/OVN-K/StackRox/Gateway API CRDs), apiVersion vs kind, OpenShift-only APIs on vanilla Kubernetes, removed/deprecated APIs, selector wiring.

Input parameters:

- `manifests` (string, required): One or more YAML documents (Kubernetes/OpenShift objects).
- `platform` (string): Target platform.
- `version`: Platform version, e.g. '4.22' (OCP) or '1.35'.

### `kubenoob_audit_manifests` (~186 tokens)

Audit manifests

Full deterministic audit: security, network exposure, storage access modes, reliability and red-team scenarios. Findings carry rule ids, line numbers, fixes, citations and matching RHACS policy names.

Input parameters:

- `exceptions`: An exception list (YAML, apiVersion kube-noob.io/v1, kind ExceptionList): each entry names a rule, a scope, an owner, a reason and an expiry date. Active entries hide the findings they cover; expired…
- `manifests` (string, required): One or more YAML documents (Kubernetes/OpenShift objects).
- `min_severity` (string): Hide findings below this severity.
- `platform` (string): Target platform.
- `stages` (array)
- `version`: Platform version, e.g. '4.22' (OCP) or '1.35'.

### `kubenoob_red_team` (~99 tokens)

Red-team manifests

Hostile-auditor scenarios: node crash, zone outage, RWX split-brain, exposure, privilege escalation, upgrade blocking, secret leaks, resource starvation, supply chain.

Input parameters:

- `manifests` (string, required): One or more YAML documents (Kubernetes/OpenShift objects).
- `platform` (string): Target platform.
- `version`: Platform version, e.g. '4.22' (OCP) or '1.35'.

### `kubenoob_fix_manifests` (~138 tokens)

Apply safe mechanical fixes

Migrates removed APIs, fixes wrong API groups, hardens securityContext, adds Route TLS, unblocks PDBs, reorders EgressFirewall rules, swaps RWO-only classes for RWX claims. Returns the diff log and manual follow-ups. Does not touch any cluster.

Input parameters:

- `harden` (boolean): Apply securityContext hardening (restricted profile).
- `manifests` (string, required): One or more YAML documents (Kubernetes/OpenShift objects).
- `platform` (string): Target platform.
- `version`: Platform version, e.g. '4.22' (OCP) or '1.35'.

### `kubenoob_clarify_requirements` (~45 tokens)

Clarify requirements

Check a (partial) generator blueprint and return blocking questions and stated assumptions.

Input parameters:

- `blueprint` (object, required): Partial blueprint; missing/invalid fields become questions.

### `kubenoob_generate_manifests` (~62 tokens)

Generate production manifests

Deterministic, audited manifests for kubernetes / openshift / rosa-classic / rosa-hcp from a blueprint (name, namespace, image, replicas, port, probes, storage, exposure, egress).

Input parameters:

- `blueprint` (required)

### `kubenoob_generate_helm_chart` (~49 tokens)

Generate a Helm chart

Same as generate_manifests but packaged as a Helm chart (Chart.yaml v2, values.yaml, values.schema.json, templates). Returns file contents.

Input parameters:

- `blueprint` (required)

### `kubenoob_search_knowledge` (~111 tokens)

Search local knowledge

BM25 search over the built-in curated knowledge and the ingested corpus (Kubernetes/OpenShift/ROSA/Helm/StackRox docs, Terraform modules, public RHACS Jira insights). Results include chunk ids to cite as [kn:...] plus source URL and license.

Input parameters:

- `limit` (integer)
- `query` (string, required)
- `source`: Source id prefix filter, e.g. 'builtin:', 'jira:ROX', 'k8s-docs'.

### `kubenoob_get_knowledge` (~57 tokens)

Read a knowledge chunk or document

Fetch the full text of a chunk id (kn:<doc>#<n>) or every chunk of a document id.

Input parameters:

- `id` (string, required): Chunk id 'kn:<doc>#<n>' or a document id.

### `kubenoob_api_history` (~49 tokens)

API removal history and version map

Removed/deprecated Kubernetes APIs relevant to a target version, and the OpenShift->Kubernetes version map.

Input parameters:

- `kind`
- `platform` (string)
- `version`

### `kubenoob_explain_rule` (~37 tokens)

Explain an audit rule

Rationale, remediation, citations for a rule id.

Input parameters:

- `rule_id` (string, required): e.g. KN-S001

### `kubenoob_list_rules` (~22 tokens)

List audit rules

All rule ids with stage, category and default severity.

### `kubenoob_diagnose` (~194 tokens)

Diagnose symptoms offline

Match pasted events / describe output / logs / CLI errors or an Alertmanager webhook payload against troubleshooting playbooks, ranked by matching patterns and by the signals the text carries (alert names, reasons); returns the signals, ranked root causes, read-only checks with names filled in, fixes, reported issues for the version and policy denials.

Input parameters:

- `limit` (integer)
- `platform`
- `text` (string, required): Events, `describe` output, logs, CLI errors, status JSON, Ceph health output (`ceph health detail`, `ceph status`, their JSON or a CephCluster) or an Alertmanager webhook payload (its alerts are read…
- `version`: The cluster's OpenShift version (4.20 or 4.20.8): leaves out reported issues already fixed there.

### `kubenoob_extract_signals` (~119 tokens)

Extract signals

Read the canonical names in an error: Alertmanager alert names (webhook payload or text), event and ClusterOperator condition reasons, container reasons, admission rules, components and normalised error templates, plus the alerts its words imply. Returns each signal with where it was found, the catalogue entry (components, playbooks, upstream source) and the playbooks it points at. Read-only and offline.

Input parameters:

- `text` (string, required): An Alertmanager payload, events, a ClusterOperator, pod status, logs or an error in words.

### `kubenoob_insight` (~213 tokens)

What is this, and what does it say?

Start here for anything the user pastes. Names what the input is (events, pod status, logs, an Alertmanager payload, a policy denial, a ticket, manifests, a Helm template, a build log, a Containerfile, an SBOM or scanner report, a packet trace, must-gather paths, a question; several at once) and runs every analyser that applies: diagnosis with reported issues and team memory, the denial explainer, the audit, the documentation. Returns every finding with its source, read-only next steps and what was not analysed and why. Read-only, local.

Input parameters:

- `platform`
- `text` (string, required): Anything pasted: events, describe output, logs, an Alertmanager payload, Ceph health output (ceph health detail or ceph status, text or JSON), a policy denial, a ticket, manifests or a Helm template,…
- `version`

### `kubenoob_ticket_changes` (~129 tokens)

What changed in Red Hat Jira

Reconcile the local copy of Red Hat's public Jira: tickets fixed (with fix versions), closed as not a bug, won't fix or duplicate, reopened, given a fix version or opened since a date, with links, and the open tickets per project and verdict. Read-only and local; each sync records the changes.

Input parameters:

- `kinds` (array)
- `limit` (integer)
- `project`
- `since` (string): How far back: 2d, 36h, 90m or a date such as 2026-10-25.

### `kubenoob_known_issues` (~175 tokens)

Is this a reported issue?

Match an error or symptom against the issues listed in the OpenShift release notes (known issues and issues fixed in each update) and, when this install keeps a local copy of Red Hat's public Jira, against those tickets too. Returns the issue id and link, what became of it (fixed and in which version, still open, closed as not a bug, won't fix or a duplicate), the workaround and Red Hat's remarks from the comments; with `version`, only issues that can affect that version.

Input parameters:

- `limit` (integer)
- `platform`
- `text` (string, required): An error message, events, logs or a symptom in words.
- `version`: The cluster's OpenShift version (4.20 or 4.20.8): keeps only issues that can affect it.

### `kubenoob_upgrade_risks` (~219 tokens)

Known risks for an OpenShift update

Before updating OpenShift from one x.y.z version to another: the risks Red Hat declares for that update in the public update graph (conditional updates, as an OpenShift Update Service serves them), from a bundled snapshot, offline. Each risk has its name, message, link, the version that fixes it and a verdict: applies (declared for every cluster), check (one fact decides it, with the read-only command or must-gather file that shows it) or cannot evaluate offline (its PromQL, as written). Whether the update is in your channel is not checked.

Input parameters:

- `arch`: The release architecture (multi for a multi-architecture payload). Without it, every architecture is checked and a risk declared for some of them only says which.
- `current` (string, required): The OpenShift version the cluster runs, x.y.z, e.g. 4.20.3.
- `target` (string, required): The version to update to, x.y.z, e.g. 4.21.4.

### `kubenoob_ticket` (~127 tokens)

Look up a Red Hat Jira ticket

One ticket from this install's local copy of Red Hat's public Jira (OCPBUGS, ROX, HOSTEDCP...): its status, what became of it, fix versions and whether `version` already has the fix, the workaround and remarks from the comments, and linked tickets. Local data only; nothing is fetched.

Input parameters:

- `key` (string, required): A Red Hat Jira key, e.g. OCPBUGS-12345 or ROX-30000.
- `version`: The cluster's OpenShift version: says whether the fix is already in it.

### `kubenoob_explain_denial` (~131 tokens)

Why was this denied?

Explain an admission denial policy by policy: Kyverno, OPA Gatekeeper, ValidatingAdmissionPolicy, Pod Security Admission, OpenShift SCC, RHACS, ResourceQuota, LimitRange or RBAC. Returns the policy and rule, the failing field, read-only commands with names filled in, the fix (with a patch for Pod Security and RBAC) and the audit rules that catch it before deploy.

Input parameters:

- `platform`
- `text` (string, required): The denial as printed: `kubectl apply` or `oc apply` output, a FailedCreate event or a Warning.

### `kubenoob_policy_generate` (~274 tokens)

Turn audit rules into admission policies

Generate ValidatingAdmissionPolicy (with binding) and/or Kyverno ValidatingPolicy YAML from kube-noob's audit rules, in audit (warn and record) or enforce mode, for a platform. One policy per rule decidable from one object; each names its rule, fix and source. Rules that need other objects or that the API server already enforces are listed with the reason. Nothing is applied.

Input parameters:

- `engines` (array): vap: ValidatingAdmissionPolicy + binding (built into Kubernetes 1.30+); kyverno: Kyverno ValidatingPolicy (policies.kyverno.io/v1, Kyverno 1.18+).
- `exceptions`: An exception list (YAML, kube-noob.io/v1 ExceptionList): active entries become exemptions in their rule's policy (with the ReplicaSets and pods their workloads make); expired or refused ones are list…
- `exclude_namespaces` (array): Namespaces the policies skip, besides kube-system, kube-public and kube-node-lease.
- `mode` (string): audit warns and records; enforce refuses
- `platform` (string)
- `rules` (array): Rule ids such as KN-S001 (default: every rule).
- `version`: OpenShift (4.20) or Kubernetes (1.33)

### `kubenoob_policy_migrate_check` (~234 tokens)

Check legacy Kyverno policies for their CEL form

Kyverno 1.20 removes the kyverno.io ClusterPolicy, Policy, CleanupPolicy and legacy PolicyException. Lint them rule by rule against the policies.kyverno.io types: direct, inverted (a deny or a negated pattern: the CEL validation must state what is allowed), manual (JMESPath, API calls, anchors, strategic merge patches) or blocked (no documented CEL equivalent), each with the field path, the target kind, the reason and the Kyverno documentation section (pinned commit). Rules that map directly get a draft CEL policy and a kyverno test fixture skeleton to prove it. Nothing is applied or rewritten.

Input parameters:

- `drafts` (boolean): Include a draft CEL policy for each rule whose fields all map directly, and a kyverno test fixture skeleton per policy (good and bad resources run against the legacy rule and the draft).
- `policies` (string, required): One or more legacy Kyverno policies (YAML): kyverno.io ClusterPolicy, Policy, ClusterCleanupPolicy, CleanupPolicy or PolicyException. Other documents are listed and skipped; Secrets are not read.

### `kubenoob_posture_scan` (~142 tokens)

Attack paths in manifests

Rank the paths from an exposure (Route, Ingress, LoadBalancer or NodePort Service) to what a compromised pod could do: node access (privileged, hostPath, host namespaces) or Kubernetes API rights through its ServiceAccount token (read Secrets, exec, create workloads, escalate). Score = exposure x blast radius; every step names the field that proves it, with a fix. Secret objects are dropped unread.

Input parameters:

- `manifests` (string, required): Routes, Ingresses, Services, workloads, ServiceAccounts and RBAC objects (YAML). Secret objects are dropped unread.
- `top` (integer): How many ranked paths to return.

### `kubenoob_build_diagnose` (~172 tokens)

Diagnose a failed build log

Read a failed GitHub Actions, Jenkins, Tekton or OpenShift build log: the failing step (and why it is that step), the error line and its template, the cause class (dependency fetch, compile, test, image push, registry auth, quota, timeout, out of memory, permissions) with its evidence, reported issues, team memory and the fix for that CI system. Read-only.

Input parameters:

- `log` (string, required): A failed build or pipeline log: GitHub Actions, Jenkins, Tekton (tkn ... logs) or an OpenShift build (oc logs build/<name>). The end of the log matters most: when cutting, keep the end.
- `platform`
- `version`: The cluster's OpenShift version, for reported issues that may apply.

### `kubenoob_rhacs_compare` (~180 tokens)

Compare RHACS policies with kube-noob's rules

Map every policy in an RHACS (StackRox) export to kube-noob rules by name and criteria: overlap (same setting, with severity and scope differences), related (the same risk seen through image, runtime or API-event data), gap (a deploy-time setting kube-noob has no rule for), outside (image contents, runtime behaviour, API events, label conventions) or unexplained (criteria kube-noob does not know). Lists disagreements and the rules no policy covers. Local only.

Input parameters:

- `outcomes` (array): Only return policies with these outcomes (default: all).
- `policies` (string, required): An RHACS policy export as JSON: {"policies": [...]} from the RHACS portal (Export policy to JSON) or POST /v1/policies/export, a list of policies, or one policy.

### `kubenoob_vuln_report` (~394 tokens)

Assess scanner output: VEX, exploitation, reachability

Read Trivy or Grype JSON, CycloneDX or SPDX SBOMs, or an RHACS image scan into one finding per package, version and CVE (with the fix version); apply Red Hat VEX (a not-affected or already-fixed finding drops out, citing the statement); mark CISA KEV entries; and, with the manifests, rank by exposure, privileges and RBAC reach with each finding's attack path. SBOM packages are matched against Red Hat VEX. Local only.

Input parameters:

- `image`: Treat every report as this image (registry/repo:tag or @sha256:...).
- `kev`: Optional: the CISA KEV catalog JSON (known_exploited_vulnerabilities.json, CC0).
- `manifests`: Optional: the YAML that runs the images; findings are then ranked by exposure and privileges and shown with their attack path.
- `products` (array): Red Hat product CPE prefixes the images belong to (default: from the RHEL release in the report, e.g. cpe:/o:redhat:enterprise_linux:9).
- `reports` (array, required): Scanner output as JSON text: Trivy (trivy image -f json [--list-all-pkgs]), Grype (grype -o json), a CycloneDX or SPDX 2 JSON SBOM, or an RHACS image (GET /v1/images/{id}). Reports of the same image…
- `top` (integer): How many ranked findings to return.
- `trust_report_vex` (boolean): Honour a CycloneDX report's own analysis (not_affected, resolved, false_positive). Off by default: the findings it marks are kept, with a note.
- `vex` (array): Optional Red Hat CSAF VEX documents (JSON) to apply on top of the local redhat-vex corpus.

### `kubenoob_threat_model` (~129 tokens)

STRIDE threat model of an application

From manifests: entry points, trust boundaries, data stores and identities, and per element the STRIDE threats with status (open, mitigated, not assessed), the evidence, the kube-noob rules, generated admission policies and RHACS policies that mitigate each, and MITRE ATT&CK for Containers technique ids. Deterministic; Secrets are dropped unread.

Input parameters:

- `manifests` (string, required): The application's YAML.
- `platform`
- `reports` (array): Optional scanner reports of its images, to assess public-facing exploits (threat TM-E01).
- `version`

### `kubenoob_posture_report` (~59 tokens)

Latest drift and policy report

The newest daily report in this install's data folder: objects added, removed and changed since the previous snapshot (with the fields that changed), findings new and fixed, and open findings by namespace, owner and rule. Local data only.

### `kubenoob_check_network_policy` (~236 tokens)

Would this traffic be allowed?

Evaluate NetworkPolicies offline: can the source reach the destination on this port? Checks egress from the source and ingress to the destination, names the policy and rule that decide each, says why the other rules did not match, and proposes the smallest NetworkPolicy that would allow it.

Input parameters:

- `default_namespace` (string): For objects without one.
- `destination` (string, required): Where it goes: namespace/name of a workload (namespace/kind/name when names clash), namespace:key=value,... for a set of pod labels, or an IP address / CIDR outside the cluster.
- `manifests` (string, required): The NetworkPolicies and the workloads they apply to (Deployments, Pods ...); add Namespace objects when policies select namespaces by label.
- `platform`
- `port` (required): Destination port number (1-65535) or a named container port.
- `protocol` (string)
- `source` (string, required): Where the connection starts: namespace/name of a workload (namespace/kind/name when names clash), namespace:key=value,... for a set of pod labels, or an IP address / CIDR outside the cluster.

### `kubenoob_incidents` (~74 tokens)

Incidents the watch has seen

Open (or resolved) incidents from the local incident ledger: workload, signal, how often it came back, the diagnosis and what changed before it started. Read this first when asked what is wrong.

Input parameters:

- `limit` (integer)
- `namespace`
- `status` (string): Which incidents to list.

### `kubenoob_incident` (~72 tokens)

One incident in full

An incident with its evidence (redacted), diagnosis, policy denials, reported issues, rollout change, every occurrence, the fixes a person confirmed, and confirmed fixes for the same problem elsewhere.

Input parameters:

- `id` (string, required): Incident id, e.g. inc-3fa94c0e12.

### `kubenoob_incident_confirm` (~124 tokens)

Remember the fix for an incident

AFTER the user confirms it worked: store the cause and fix on the incident (and as a learning note), so the next occurrence comes with it. Summaries only; never leaves the machine.

Input parameters:

- `cause` (string, required): The confirmed root cause, in words.
- `confirmed_by_user` (boolean, required): True only after the user explicitly confirmed this cause and fix worked.
- `fix` (string, required): What fixed it, in words (no manifests).
- `id` (string, required): Incident id, e.g. inc-3fa94c0e12.

### `kubenoob_learn_tracks` (~30 tokens)

List learning tracks

Tracks, lessons, exercises and the learner's progress.

Input parameters:

- `learner` (string)

### `kubenoob_learn_lesson` (~59 tokens)

Open a lesson

Lesson content with objectives, key points and citations. A shared HTTP server records no progress, so the learner id only selects whose tally to show when one is kept.

Input parameters:

- `learner`
- `lesson_id` (string, required)

### `kubenoob_learn_exercise` (~31 tokens)

Get an exercise

Exercise prompt, starter YAML, hints and points.

Input parameters:

- `exercise_id` (string, required)

### `kubenoob_learn_submit` (~67 tokens)

Submit an exercise answer

Grade YAML offline with the audit engine; awards credits and returns feedback. A shared HTTP server grades the same way but records nothing, and says so in the result.

Input parameters:

- `answer` (string, required)
- `exercise_id` (string, required)
- `learner` (string)

### `kubenoob_learn_quiz` (~80 tokens)

Quiz

Fetch a quiz question (no choice) or answer it (choice index). A shared HTTP server marks the answer the same way but records nothing, and says so in the result.

Input parameters:

- `choice`: Omit to fetch the question; set to answer it.
- `learner` (string)
- `question_id` (string, required)

### `kubenoob_learn_progress` (~25 tokens)

Learner progress

Credits earned and completed items.

Input parameters:

- `learner` (string)

### `kubenoob_grade_answer` (~107 tokens)

Grade a model answer (enforcer + credit system)

Deterministic reward for a completion against a benchmark task: task correctness (audit engine or QA rules), source-attribution credit for valid [kn:...] citations, format, penalties.

Input parameters:

- `completion` (string, required)
- `task`: Inline task. Its mustMention / mustNotMention / matches entries are matched as literal text, not regular expressions (only built-in benchmark tasks use regular expressions).
- `task_id`: Benchmark task id; or pass `task` inline.

### `kubenoob_learning_summary` (~51 tokens)

Show what kube-noob has learned locally

The user's environment profile (platform, versions, conventions), confirmed troubleshooting notes (cite as [kn:local-N#0]) and the most frequent playbooks/rules. Read this before tailoring advice.

### `kubenoob_learning_note_add` (~127 tokens)

Remember a confirmed fix

Save a short symptom -> cause -> fix note to the local learning file AFTER the user confirms it worked. Summaries only: credentials, manifests and raw logs are rejected. Never leaves the machine.

Input parameters:

- `cause` (string, required): The confirmed root cause.
- `confirmed_by_user` (boolean, required): True only after the user explicitly confirmed this cause and fix worked.
- `fix` (string, required): What fixed it, in words (no manifests).
- `platform`
- `symptom` (string, required): What was observed, in one or two sentences.
- `tags` (array)

### `kubenoob_learning_profile_set` (~83 tokens)

Remember the user's environment

Save platform, versions and team conventions the user stated, so later answers fit their setup.

Input parameters:

- `conventions`: Team conventions, e.g. 'namespaces are <team>-<env>'.
- `platform`
- `versions` (object): Keys kubernetes|openshift|helm|rhacs|rosa, values like '4.22'.

### `kubenoob_config_status` (~27 tokens)

Show configuration

Effective configuration (webEnabled, cluster access, model), version and knowledge stats.

### `kubenoob_code_report` (~367 tokens)

Assess SAST findings: where the code ships and who runs it

Read the SARIF that Semgrep, Bandit, SpotBugs/FindSecBugs, ESLint or CodeQL wrote (kube-noob has no analysis engine of its own): one finding per file, line and CWE across tools, suppressed and fixed results excluded with the reason, lint kept apart. With Containerfiles, each file is followed into the images that ship it (copied or built; tests and tools are not shipped); with manifests, findings rank by exposure and privileges with the attack path. With scanner reports and dependency files, each language-package vulnerability points at the file and line to change. Local only.

Input parameters:

- `containerfiles` (array): Containerfiles, to know which images ship each file.
- `dependency_files` (object): Dependency files by repository path (requirements.txt, package.json, package-lock.json, pom.xml, go.mod, ...), to find the line that declares a vulnerable package.
- `include_quality` (boolean): Also list lint and quality results (never ranked).
- `manifests`: YAML that runs the images: ranks by exposure and privileges.
- `reports` (array): Trivy or Grype JSON or a CycloneDX report of an image: each language-package vulnerability points at the dependency file and line that declares it.
- `sarif` (array): SARIF 2.1.0 as JSON text from Semgrep, Bandit, SpotBugs/FindSecBugs, ESLint or CodeQL (any SARIF producer works). The same file, line and CWE from several tools become one finding.
- `source_roots` (array): Absolute directories the scanners ran in (the CI checkout), so absolute paths map to the repository.
- `top` (integer): How many ranked findings to return.

### `kubenoob_containerfile_audit` (~141 tokens)

Audit a Containerfile

Static checks of a Containerfile or Dockerfile: base images pinned by digest, a non-root USER, no credentials in ENV, ARG, LABEL, RUN or copied files, no download piped into a shell, package caches cleaned, a health check or probes, a multi-stage build. Each finding names its fix and source. The CLI (kube-noob build audit) also reads the build context and the built image's layers.

Input parameters:

- `containerfile` (string, required): The Containerfile or Dockerfile text.
- `manifests`: Optional: the workload YAML that runs the image; its readiness or liveness probes satisfy the health check.

### `kubenoob_analyze_must_gather` (~224 tokens)

Analyse a must-gather

Open an OpenShift must-gather (or oc adm inspect output) safely and say what is wrong, most severe first: the cluster version and update, cluster operators, nodes, machine config pools, OLM operators, pods, warning events and etcd log hints. Each finding has its evidence file, its signals, read-only commands to confirm it, and the known OpenShift bugs and team memory entries that match it for the version the cluster runs. Nothing is extracted or run and Secrets are never read. Local: reads the path you give on this machine.

Input parameters:

- `case_draft` (boolean): Also return caseDraft: a support case draft with placeholders for what only you know.
- `path` (string, required): Absolute path of a must-gather directory or .tar, .tar.gz or .tgz archive on the machine the server runs on (under mustGather.allowedDir when it is set). Nothing is extracted or run; Secrets are neve…
- `top` (integer): How many findings to return, most severe first.

## Diagnostics

Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/aashishmahajan-kube-noob/kube-noob#diagnostics

## Score history

- 2026-11-05: 62
- 2026-11-04: 77
- 2026-11-03: 82
- 2026-11-02: 81
- 2026-11-01: 81
- 2026-10-31: 80
- 2026-10-30: 65
- 2026-10-29: 65
- 2026-10-28: 64
- 2026-10-27: 63

## Common questions

### What is the kube-noob MCP server?

kube-noob is an MCP server listed in the public MCP registry as io.github.aashishmahajan/kube-noob. Kubernetes, OpenShift, ROSA HCP, Helm and RHACS audit, debugging and cited docs. No AI inside. This page covers its PyPI package (kube-noob).

### Is the kube-noob MCP server safe to use?

kube-noob scores 62 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the kube-noob MCP server expose?

kube-noob exposes 47 tools: kubenoob_run_protocol, kubenoob_validate_manifests, kubenoob_audit_manifests, kubenoob_red_team, kubenoob_fix_manifests, and 42 more. Their descriptions and schemas cost roughly 5,906 tokens of context every time the server is loaded.

### Is the kube-noob MCP server still maintained?

kube-noob is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the kube-noob MCP server under?

kube-noob declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- PyPI project: https://pypi.org/project/kube-noob/
- Socket report: https://socket.dev/pypi/package/kube-noob
- Changelog RSS feed: https://verifymcp.io/servers/aashishmahajan-kube-noob/kube-noob.xml
- Changelog JSON feed: https://verifymcp.io/servers/aashishmahajan-kube-noob/kube-noob.json
- HTML version of this page: https://verifymcp.io/servers/aashishmahajan-kube-noob/kube-noob