Skip to main content
Glama

Recent failed tasks

recent_task_failures
Read-onlyIdempotent

Lists recently failed Proxmox tasks grouped by type, with time-window and task-type filters, to help diagnose incidents and identify operations needing attention.

Instructions

List tasks that failed recently, grouped by type. Good first stop after an incident.

Based on the cluster-wide recent task list, which Proxmox keeps short; very old failures may no longer be included regardless of the window.

Input Schema

NameRequiredDescriptionDefault
hoursNoTime window to look back, in hours.
limitNoMaximum number of failed tasks to return.
task_typeNoe.g. 'vzdump', 'qmigrate', 'qmstart'.

Output Schema

NameRequiredDescriptionDefault
tasksYes
totalYes
by_typeYes
window_hoursYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish read-only/idempotent safety, so the description's real contribution is the non-obvious data-completeness caveat: results derive from a cluster-wide list Proxmox keeps short, so very old failures may be missing regardless of the requested window. That materially changes how an agent should interpret empty or thin results and cannot be inferred from the structured fields.

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 short sentences with the core purpose front-loaded and the caveat following. Every clause earns its place; nothing is redundant with the schema or annotations.

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?

An output schema exists, so return values need no explanation, and the three parameters are fully documented in the schema. Purpose, incident-triage positioning, and the retention caveat are all covered, leaving nothing an agent needs to call this correctly.

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 coverage is 100%, so the baseline is 3 — the hours/limit/task_type meanings are already documented. The description adds value by warning that the `hours` window may not be honored for very old failures, which reframes how that parameter should be trusted, pushing it above baseline.

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 tasks that failed recently") plus a distinct output shape ("grouped by type"). An agent can immediately separate this from get_task_status (single task) and cluster_health (overall health) without opening any 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?

"Good first stop after an incident" gives clear situational guidance for when to reach for this tool. It stops short of naming alternatives or exclusion cases (e.g. when to prefer get_task_status for a specific task), so it lands at 4 rather than 5.

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