Skip to main content
Glama
BenedatLLC

Kubernetes Tools MCP Server

by BenedatLLC

get_service_summaries

List Kubernetes services with summaries including name, type, cluster IP, ports, and labels for a specific namespace or all namespaces.

Instructions

Retrieves a list of ServiceSummary objects for services in a given namespace or all namespaces. Similar to kubectl get services.

Parameters
----------
namespace : Optional[str], default=None
    The specific namespace to list services from. If None, lists services from all namespaces.

Returns
-------
list of ServiceSummary
    A list of ServiceSummary objects, each providing a summary of a service's status with the following fields:

    name : str
        Name of the service.
    namespace : str
        Namespace in which the service is running.
    type : str
        Type of the service (ClusterIP, NodePort, LoadBalancer, ExternalName).
    cluster_ip : Optional[str]
        Cluster IP address assigned to the service (None for ExternalName services).
    external_ip : Optional[str]
        External IP address if applicable (for LoadBalancer services).
    ports : list[PortInfo]
        List of ports (and their protocols) exposed by the service.
    age : datetime.timedelta
        Age of the service (current time minus creation timestamp).
    selector : dict[str, str]
        The label selector the service uses to choose backing pods. Empty
        for services without a selector (e.g. ExternalName, or manually
        managed Endpoints).
    labels : dict[str, str]
        Labels on the service object.
    annotations : dict[str, str]
        Annotations on the service object.

Raises
------
K8sConfigError
    If unable to initialize the K8S API.
K8sApiError
    If the API call to list services fails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
namespaceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.1.0
    • changedOutput schema / $defs / ServiceSummary / description
      Previous value: -"A summary of a service's status like returned by `kubectl get servicess`"New value: +"A summary of a service's status like returned by `kubectl get services`,\nplus the pod `selector` and the service's labels/annotations."
    • addedOutput schema / $defs / ServiceSummary / properties / annotations
      Added value: +{
      +  "additionalProperties": {
      +    "type": "string"
      +  },
      +  "title": "Annotations",
      +  "type": "object"
      +}
    • addedOutput schema / $defs / ServiceSummary / properties / labels
      Added value: +{
      +  "additionalProperties": {
      +    "type": "string"
      +  },
      +  "title": "Labels",
      +  "type": "object"
      +}
    • addedOutput schema / $defs / ServiceSummary / properties / selector
      Added value: +{
      +  "additionalProperties": {
      +    "type": "string"
      +  },
      +  "title": "Selector",
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and mostly succeeds: it discloses the read-only nature ('Retrieves'), the two failure modes (K8sConfigError on API init, K8sApiError on list failure), and non-obvious semantics such as cluster_ip being None for ExternalName services and selector being empty for selectorless services.

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?

The opening sentence is front-loaded and efficient, but the bulk of the text is an exhaustive field-by-field enumeration of the return object, which duplicates what the output schema already provides. That block is the majority of the description and does not earn its place.

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 tool is a simple single-parameter list operation and the description covers scope, the one parameter, error conditions, and edge-case field semantics. It is complete, though it spends effort re-documenting return fields that the output schema already carries.

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

Parameters5/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: it names the single parameter, marks it optional with default None, and explains the behavioral consequence of None (list across all namespaces) that the schema alone cannot convey.

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 ('Retrieves a list of ServiceSummary objects for services') and scopes it precisely to a namespace or all namespaces. The 'kubectl get services' analogy and the ServiceSummary naming make it trivially distinguishable from siblings like get_node_summaries or get_pod_summaries.

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 scope statement (list services in one namespace or all), but there is no explicit when-to-use/when-not guidance and no named alternative among the many *_summaries siblings. An agent can infer intent, but nothing routes it away from this tool when another would be better.

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