Skip to main content
Glama
BenedatLLC

Kubernetes Tools MCP Server

by BenedatLLC

get_pod_events

Retrieve Kubernetes pod events to diagnose issues and monitor pod lifecycle changes in your cluster.

Instructions

Get events for a specific Kubernetes pod. This is equivalent to the kubectl command:
`kubectl get events -n NAMESPACE --field-selector involvedObject.name=POD_NAME,involvedObject.kind=Pod`

Parameters
----------
pod_name : str
    Name of the pod to retrieve events for.
namespace : str, optional
    Namespace of the pod (default is "default").

Returns
-------
list of EventSummary
    List of events associated with the specified pod. Each EventSummary has the following fields:

    last_seen : Optional[datetime.datetime]
        Timestamp of the last occurrence of the event (if available).
    type : str
        Type of the event.
    reason : str
        Reason for the event.
    object : str
        The object this event applies to.
    message : str
        Message describing the event.
Raises
------
K8sConfigError
    If unable to initialize the K8S API.
K8sApiError
    If the API call to list events fails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pod_nameYes
namespaceNodefault

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Pydantic model defining the output structure for events returned by get_pod_events.
    class EventSummary(BaseModel):
        """This is the representation of a Kubernetes Event"""
        last_seen: Optional[datetime.timedelta]  # Time since event occurred
        type: str
        reason: str
        object: str
        message: str
  • Core handler function that fetches pod events from Kubernetes API using field selector and maps to EventSummary objects.
    def get_pod_events(pod_name: str, namespace: str = "default") -> list[EventSummary]:
        """
        Get events for a specific Kubernetes pod. This is equivalent to the kubectl command:
        `kubectl get events -n NAMESPACE --field-selector involvedObject.name=POD_NAME,involvedObject.kind=Pod`
    
        Parameters
        ----------
        pod_name : str
            Name of the pod to retrieve events for.
        namespace : str, optional
            Namespace of the pod (default is "default").
    
        Returns
        -------
        list of EventSummary
            List of events associated with the specified pod. Each EventSummary has the following fields:
    
            last_seen : Optional[datetime.datetime]
                Timestamp of the last occurrence of the event (if available).
            type : str
                Type of the event.
            reason : str
                Reason for the event.
            object : str
                The object this event applies to.
            message : str
                Message describing the event.
        Raises
        ------
        K8sConfigError
            If unable to initialize the K8S API.
        K8sApiError
            If the API call to list events fails.
        """
        global K8S
        if K8S is None:
            K8S = _get_api_client()
        logging.info(f"get_pod_events(pod_name={pod_name}, namespace={namespace})")
        field_selector = f"involvedObject.name={pod_name}"
        events = K8S.list_namespaced_event(namespace, field_selector=field_selector)
        now = datetime.datetime.now(datetime.timezone.utc)
        return [
            EventSummary(
                last_seen=(now - event.last_timestamp) if event.last_timestamp else None,
                type=event.type,
                reason=event.reason,
                object=getattr(event.involved_object, 'name', pod_name),
                message=event.message,
            )
            for event in events.items
        ]
  • Registration of get_pod_events in the TOOLS list for MCP integration.
    TOOLS = [
        get_namespaces,
        get_node_summaries,
        get_pod_summaries,
        get_pod_container_statuses,
        get_pod_events,
        get_pod_spec,
        get_logs_for_pod_and_container,
        get_deployment_summaries,
        get_service_summaries
    ]
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well by detailing the kubectl equivalent (clarifying the query logic), listing return fields with types, and specifying error conditions (K8sConfigError, K8sApiError). It doesn't cover rate limits or auth needs, but gives solid operational context.

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

Conciseness5/5

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

Well-structured with clear sections (description, parameters, returns, raises), front-loaded purpose, and no wasted sentences. Each part adds value, such as the kubectl analogy and detailed return field explanations.

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?

Given the tool's moderate complexity (2 params, no annotations), the description is highly complete: it explains the action, parameters, return structure (with output schema details), and error cases. The output schema is present, so no need to redundantly explain returns.

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 fully. It explicitly documents both parameters (pod_name, namespace), including the namespace default value ('default') and their purposes, adding crucial meaning beyond the bare schema.

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 clearly states the specific action ('Get events for a specific Kubernetes pod') and resource ('pod'), distinguishing it from siblings like get_pod_summaries or get_logs_for_pod_and_container by focusing exclusively on events. The kubectl command analogy reinforces the precise scope.

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?

It implicitly suggests usage when needing pod events, but lacks explicit guidance on when to choose this over alternatives like get_pod_summaries (which might include event data) or get_logs_for_pod_and_container (for logs vs. events). No exclusions or prerequisites are mentioned.

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/BenedatLLC/k8stools'

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