shopware-mcp

Scheduled tasks

scheduled_tasks_list

Read-onlyIdempotent

List Shopware scheduled tasks with status, intervals, last/next runs, and overdue, failed, or stuck flags to diagnose stale indexes, thumbnails, or unsent mail.

Instructions

Shopware's scheduled tasks (indexing, cleanups, cache invalidation, plugin jobs) with status, interval, last and next run, and per task whether it is overdue past a grace period, failed, or stuck running for over a day. Many overdue tasks with no recent last run mean the scheduler or message worker is not running, which shows up as stale search results, missing thumbnails and unsent mails. Read-only. Returns { total, summary: { byStatus, overdue, failed, stuck, longestOverdueMinutes, lastRun }, tasks[], problems[], truncated }.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "scheduled_tasks_list"
  }
}

Input Schema

Name	Required	Description	Default
`graceMinutes`	No	A waiting task past its next run by more than this counts as overdue
`onlyProblems`	No	Return only overdue, failed or stuck tasks

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.11.1Nov 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds real behavioral context: the grace-period logic behind 'overdue', the >1 day threshold for 'stuck', the failed state, and the causal interpretation of a mass of overdue tasks. It also discloses the return envelope including a 'truncated' flag, which is not derivable from any structured field.

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

Conciseness4/5

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

Front-loaded with the resource and its payload, then the diagnostic interpretation, then the return shape — a sensible order with no filler sentences. It is dense but long for a two-parameter read tool; the symptom list ('stale search results, missing thumbnails, unsent mails') is value-adding rather than padding, though the return-shape sentence is heavy.

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?

With no output schema, the description compensates by spelling out the full return envelope (total, summary fields, tasks[], problems[], truncated). Combined with the overdue/stuck semantics and the operator-facing interpretation, an agent has everything needed to call and read this tool correctly.

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 description coverage is 100%, so graceMinutes and onlyProblems are already fully documented in the schema with defaults and bounds. The description only echoes the concept of a grace period and adds no format or interaction detail beyond it, which is the expected baseline when the schema does the heavy lifting.

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+resource ('Shopware's scheduled tasks') and enumerates exactly what is reported: status, interval, last and next run, plus per-task overdue/failed/stuck classification. Nothing in the sibling list (shop_diagnose, shop_pulse, agent_readiness) overlaps ambiguously with this task-level listing, so an agent can route here without opening the 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?

The description gives clear diagnostic framing: many overdue tasks with no recent last run indicate the scheduler or message worker is down, surfacing as stale search results, missing thumbnails and unsent mails. It does not, however, name when to prefer this over sibling diagnostics tools such as shop_diagnose or shop_pulse, so the alternative-routing half of the guidance is absent.

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