shopware-mcp

Simulate a checkout

checkout_simulate

Read-only

Simulate a customer checkout via Shopware's Store API to see calculated prices, discounts, shipping, taxes and cart errors, and learn why a code or an order fails.

Instructions

See the checkout the way a customer does: puts products (and promotion codes) into a throwaway cart of a sales channel through Shopware's own Store API, as a guest shipping to a country or as a given customer with their group, prices and rules, and returns what Shopware calculates: prices per item next to the listing price, discounts, shipping, taxes, total, which payment and shipping methods the customer is offered, which are hidden and by which rule, and every cart error with a plain explanation (country not assigned, code expired, product not visible, stock). Nothing is ordered and the cart is deleted afterwards; as a customer, extensions that react to saved carts (abandoned-cart mailers) see it like any other cart of that customer. Use it for 'why can't this customer order?', 'why does this code not work?' or 'what does shipping to Switzerland cost?'. Returns { salesChannel, as, canOrder, items[], promotions[], shipping, totals, problems[], paymentMethods, shippingMethods }.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "items": "<items>"
    },
    "name": "checkout_simulate"
  }
}

Input Schema

Name	Required	Description
`items`	Yes	Products and quantities for the cart
`country`	No	Shipping country of a guest, as ISO code
`salesChannel`	No	Sales channel id or name; default: the first active storefront
`paymentMethod`	No	Payment method name to select
`customerNumber`	No	Simulate as this customer: group, prices, rules and default addresses
`promotionCodes`	No	Promotion codes to redeem
`shippingMethod`	No	Shipping method name to select

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds the side-effect profile the annotations cannot: nothing is ordered, the cart is deleted afterwards, yet when simulating as a customer, extensions reacting to saved carts (abandoned-cart mailers) will see the cart like any real one. It also discloses what the result contains, including which payment/shipping methods are hidden and by which rule. That is exactly the kind of downstream-effect warning an agent needs before invoking on a live shop.

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?

Very dense but every clause carries information an agent needs – the mode selection, the return contents, the side-effect caveat, and the use cases. The opening is slightly poetic ("See the checkout the way a customer does") and the return-field list is buried at the end rather than front-loaded, but there is little outright waste.

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 seven parameters, no output schema, and an openWorld/read-only hint set, the description carries the right load: it names the response shape, explains error reporting (cart errors with plain explanations such as country not assigned, expired code, invisible product, stock), and warns about external side effects. Nothing an agent needs in order to call this 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 the baseline is 3, but the description adds real meaning: it explains that country and customerNumber are alternative guest/as-customer modes, that customer mode pulls in group, prices, rules and default addresses, and that promotion codes go into the same cart. It does not clarify precedence if both country and customerNumber are supplied, nor how paymentMethod/shippingMethod names are resolved, so it falls short of a 5.

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: it builds a throwaway cart through Shopware's Store API and returns everything Shopware calculates. It also pins down scope precisely (guest shipping to a country vs. a given customer with their group, prices and rules) and distinguishes itself from siblings like promotions_check or shipping_methods_list, which only inspect one piece rather than the whole checkout.

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?

Gives concrete triggering questions: "why can't this customer order?", "why does this code not work?" and "what does shipping to Switzerland cost?" – an agent can map a user request onto this tool immediately. It stops short of naming alternatives (promotions_check, shipping_methods_list, products_get) and saying when a cheaper read-only check is preferable to a full simulation.

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