Skip to main content
Glama

list_active_runs

List currently running Kubernetes Jobs across one namespace or all, showing owning CronJob, start time, runtime, pod counts, deadlines, and overdue runs to help spot long-running or stalled work.

Instructions

List Jobs that are running right now (one namespace or all), including Jobs not created by a CronJob. For each: owning CronJob, start time, how long it has been running, pod counts, deadline, and whether it is taking more than twice its typical duration. Longest-running and overdue Jobs first.

Input Schema

NameRequiredDescriptionDefault
limitNoMax runs to return
namespaceNoNamespace to list; omit for all namespaces

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it enumerates returned fields (owning CronJob, start time, duration, pod counts, deadline), declares sort order ('Longest-running and overdue Jobs first'), and surfaces a derived signal ('more than twice its typical duration'). It omits the implicit read-only nature and any truncation/pagination behavior when limit is hit.

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?

Two sentences, purpose front-loaded in the opening clause, followed by a tight inventory of what each row contains and the ordering rule. No filler or repetition.

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?

There is no output schema, so the description must describe returned values — it does so field by field, including the anomaly indicator and sort order. For a two-parameter read-only list tool, nothing an agent needs to call and interpret it correctly is missing.

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 coverage is 100%, so both parameters are already documented in the schema, and the description's 'one namespace or all' only restates the namespace parameter's meaning. No additional semantics such as how limit interacts with the sort order are added, so baseline 3 applies.

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 ('List Jobs that are running right now') plus scope ('one namespace or all') and explicitly extends beyond the sibling CronJob-centric tools by including Jobs not created by a CronJob. An agent can distinguish it from get_run_history or list_cronjobs without opening a schema.

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?

'running right now' clearly delimits this against historical tools, and the parenthetical 'one namespace or all' tells the agent how to scope the call. It does not name an explicit alternative (e.g. get_run_history for completed runs) or state exclusions, so it stops short of a 5.

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