Skip to main content
Glama
BenedatLLC

Kubernetes Tools MCP Server

by BenedatLLC

get_configmap

Retrieve the full contents of a Kubernetes ConfigMap by name and namespace to inspect configuration data and binary key names.

Instructions

Retrieves the full contents of a single ConfigMap.

WARNING: ConfigMaps can contain secret-shaped values (e.g. credentials stored
as plain config). When this tool is served through the k8stools MCP server, the
output passes through a redaction step by default (see the `redaction` module
and the server's `--no-redact` flag). Callers using this function directly get
the raw values and are responsible for their own redaction.

Parameters
----------
name : str
    Name of the ConfigMap.
namespace : str, optional
    Namespace of the ConfigMap (default is "default").

Returns
-------
dict[str, Any]
    A dictionary describing the ConfigMap with the following keys:

    name : str
        Name of the ConfigMap.
    namespace : str
        Namespace of the ConfigMap.
    data : dict[str, str]
        The string key/value data map (empty dict if none).
    binary_data_keys : list[str]
        Names of any binary keys. The binary values themselves are not
        returned.

Raises
------
K8sConfigError
    If unable to initialize the K8S API.
K8sApiError
    If the ConfigMap is not found or the API call fails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
namespaceNodefault

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it warns that ConfigMaps may hold secret-shaped plaintext values, explains that the MCP server redacts output by default but direct callers get raw values, and documents two failure modes (K8sConfigError, K8sApiError) plus the fact that binary values are withheld.

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

Conciseness3/5

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

Sectioned layout (warning, parameters, returns, raises) is well front-loaded, but the Returns block restates a return shape that an output schema already defines, and the redaction paragraph is lengthy. Some sentences do not earn their place for an agent that can read the schema.

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

Completeness5/5

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

For a two-parameter read tool this covers everything an agent needs: purpose, parameter meanings, redaction caveat, error conditions, and note that binary values are omitted. The existence of an output schema makes the extra Returns detail a bonus rather than a gap.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate, and it does: name is 'Name of the ConfigMap' and namespace is optional with default 'default'. It covers both parameters adequately, though it adds no syntax constraints beyond the schema types.

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?

States a specific verb and resource with scope: 'Retrieves the full contents of a single ConfigMap.' The word 'single' and 'full contents' clearly distinguishes it from the sibling get_configmap_summaries, which lists many.

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

Usage Guidelines3/5

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

Usage is implied by the single-vs-summaries naming, but the description never explicitly says when to reach for this tool over get_configmap_summaries or get_pod_spec. The redaction paragraph explains deployment context, not selection criteria.

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