Skip to main content
Glama

KSPM Cluster Posture

kspm_cluster_posture
Read-onlyIdempotent

Audit live Kubernetes cluster security posture by inspecting workloads, RBAC, NetworkPolicy, and kubelet config against the CIS benchmark. Read-only evaluation returns findings per severity.

Instructions

Evaluate live Kubernetes cluster security posture (KSPM).

    Read-only inspection of running workloads, RBAC, NetworkPolicy coverage,
    and (opt-in) kubelet config against the pinned CIS Kubernetes Benchmark.
    Distinct from image discovery: this returns SECURITY POSTURE, not a
    container-image inventory.

    Every collector carries an explicit execution state — executed / skipped
    / unevaluable (a denied or absent read) / failed — so a partial run is
    reported 'partial' with a coverage-affecting ScanRun issue and can never
    be laundered into a clean pass. The benchmark provenance, collector
    states, ScanRun outcome, and finding summary reconcile 1:1 with the REST
    /v1/kspm/clusters/posture route and the CLI evidence dict.

    Returns:
        JSON with benchmark provenance, per-collector states, the canonical
        ScanRun outcome, a finding count, and a per-severity summary.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contextNokubectl context to use (workstation fallback path only). Omit to use the in-cluster SA token.
namespaceNoKubernetes namespace to inspect (ignored when all_namespaces=True). Defaults to 'default'.default
all_namespacesNoInspect every namespace instead of a single one.
enable_nodes_configzNoOpt in to per-node kubelet /configz collection (CIS section 4.2). Off by default.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnly, idempotent, non-destructive), the description adds rich context: every collector has an explicit state (executed/skipped/unevaluable/failed), partial runs are reported as 'partial' and cannot be launder into a clean pass, and results reconcile with the REST route and CLI. This is substantial behavioral disclosure not present in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by distinguishing context and behavioral details. It is longer than average but each sentence contributes meaningful information, and the final 'Returns:' block clearly summarizes outputs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, output, and critical behavioral nuances (collector states, partial run handling). While it does not explicitly state required permissions, the mention of 'unevaluable (a denied or absent read)' implies this. The presence of an output schema reduces the need to describe return values, so the description is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and parameter descriptions are already detailed (e.g., 'Opt in to per-node kubelet /configz collection (CIS section 4.2)'). The tool description does not add significant parameter-level semantics beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pair: 'Evaluate live Kubernetes cluster security posture (KSPM)'. It clearly distinguishes itself from image discovery by stating it returns SECURITY POSTURE, not container-image inventory, which differentiates it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (live cluster posture against CIS benchmark) and explicitly states what it is NOT (image discovery). However, it does not name alternative sibling tools directly, relying more on exclusion than explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/msaad00/agent-bom'

If you have feedback or need assistance with the MCP directory API, please join our Discord server