shopware-mcp

What would a discount cost?

promotion_impact

Read-onlyIdempotent

Estimate a promotion's cost before enabling it by replaying its discount on recent orders, showing eligible orders, revenue impact, and per-order scenarios.

Instructions

Before switching a promotion on: replay its cart discount (or one you describe) on the orders of the last days and say what it would have cost: if every eligible order had used it, and at the share of orders that used a promotion so far. Respects a percentage cap and a minimum cart value; rules that limit who gets it are not evaluated, so the result is an upper bound. Read-only. Returns { orders, revenue, eligibleOrders, scenarios, averagePerOrder, capReached, note }.

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

Input Schema

Name	Required	Description
`days`	No	Orders of how many days to replay
`discount`	No	Or a discount to try: 'what if 20 % off?'
`promotionId`	No	An existing promotion, e.g. from promotions_list
`minCartValue`	No	Only carts from this value (gross)
`salesChannelId`	No	Only this sales channel

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.11.1Nov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the two scenario definitions (all eligible orders vs. the observed adoption share), the fact that eligibility rules are not evaluated so results are an upper bound, and that percentage caps and minimum cart values are respected. These are modeling caveats an agent could not infer from annotations and would otherwise misreport to a user.

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 decision the agent is supporting, then behavior, then caveat, then return shape — a sensible order. The middle sentence is long and colon-heavy, requiring a second read, which keeps it from a 5.

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 enumerates the returned keys (orders, revenue, eligibleOrders, scenarios, averagePerOrder, capReached, note), and it flags the upper-bound limitation that materially affects interpretation. Nothing an agent needs in order to call this nested-object tool correctly is missing.

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 a baseline of 3 applies, but the prose adds real meaning: it maps promotionId to "its cart discount" versus the discount object as an ad-hoc "what if 20% off", and ties "percentage cap" and "minimum cart value" to the maxValue and minCartValue behavior. It does not explain days beyond the schema's own default or the sales-channel filter, keeping it at 4.

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 names a specific verb and resource — replaying a cart discount over recent orders to compute what the promotion would have cost — which is clearly distinct from promotions_list or promotions_check. The title plus the first clause make the simulation intent unmistakable before the schema is opened.

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?

"Before switching a promotion on" gives an explicit timing trigger, and the parenthetical "(or one you describe)" clarifies the hypothetical-discount use case. It stops short of naming an alternative tool (e.g. promotions_check) or stating when this is not the right choice, so it is clear but not fully routing.

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