shopware-mcp

Shop pulse

shop_pulse

Read-onlyIdempotent

Check current order and revenue volume, the last order and payment failures against typical weekday hours. Detect unusual quiet spells that may indicate a broken checkout, payment or storefront.

Instructions

How is the shop doing right now? Orders and revenue since local midnight next to the same hours of the same weekday in previous weeks, the last order, and how unusual the current quiet spell is: the orders the same stretch brought in earlier weeks and the chance of seeing none by accident (a Poisson estimate). 'unusual' means the checkout, payment or storefront may be broken; follow up with checkout_simulate. Also compares today's failed or cancelled payments with their usual share. On a campaign day compare with last year (baseline 'last-year') or raise the expectation (expectFactor 3 on Black Friday), so a quiet spell is judged against what the day should bring. Public holidays in the compared weeks are left out (DE, AT, CH). Read-only. Returns { today, typical, change, lastOrder, silence, payments, history[] }.

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": "shop_pulse"
  }
}

Input Schema

Name	Required	Description	Default
`weeks`	No	How many previous weeks make up 'typical'
`baseline`	No	Compare with recent weeks, or with the same weekday around this day last year	recent
`holidays`	No	Leave public holidays of this country out of 'typical'; default: the time zone's country (Europe/Berlin: DE, Europe/Vienna: AT, Europe/Zurich: CH)
`timeZone`	No	IANA time zone of the shop, e.g. Europe/Berlin; default: the server's
`expectFactor`	No	Today should bring this many times the usual orders, e.g. 3 on a campaign day
`salesChannelId`	No	Only this sales channel

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.11.1Nov 6, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false), yet the description still adds real context: the statistical method (Poisson estimate of seeing zero orders by accident), the meaning of 'unusual' and its operational implication, and the fact that public holidays are excluded only for DE/AT/CH. That holiday-coverage limitation is a genuine caveat not present in the annotations. It states 'Read-only', which is redundant with readOnlyHint but not contradictory.

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?

The opening question front-loads the purpose, and the dense parenthetical clauses all carry substantive information rather than filler. Some sentences are long and packed (the Poisson / unusual-explanation clause), and 'Read-only' duplicates the annotation, but for a six-parameter statistical tool the length is proportionate. Slight tightening would improve scanability.

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?

With no output schema, the description partially compensates by listing the return keys (today, typical, change, lastOrder, silence, payments, history[]) and by explaining what the anomaly signal means and how to act on it. The holiday-scope caveat and campaign-day guidance round out what an agent needs before calling. Individual return field semantics are only named, not explained, which is the remaining gap.

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, but the description adds practical meaning: baseline 'last-year' is framed as the campaign-day comparison and expectFactor as raising the expected volume, with the rationale 'so a quiet spell is judged against what the day should bring'. That explains how weeks/baseline/expectFactor interact, which the schema documents individually but not jointly. Marginal gain, so not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description concretely defines the computation: orders and revenue since local midnight compared to the same hours on the same weekday in prior weeks, plus last order, silence anomaly, and payment-failure share. This is far more specific than the title 'Shop pulse'. It doesn't explicitly distinguish itself from near-siblings like shop_brief, sales_report, or shop_diagnose, so an agent must infer which of those to pick, but it does name checkout_simulate as the escalation path.

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?

Usage context is clear ('How is the shop doing right now?') and the description tells the agent what to do when silence is flagged: 'follow up with checkout_simulate'. It also gives conditional parameter advice for campaign days (baseline 'last-year' or expectFactor 3 on Black Friday). It does not state when *not* to use it in favor of the reporting siblings (sales_report, shop_brief), which keeps it from a 5.

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