shopware-mcp

Run customer journeys

journeys_run

Read-only

Run synthetic customer buying paths through the shop cart to verify checkout rules, promotions, payment/shipping options, and totals. Detect which journey fails and why without placing orders.

Instructions

Synthetic customers: run fixed buying paths through the shop's real cart, e.g. 'Swiss guest with code SUMMER26', 'regular customer pays by invoice', and say which one broke and why. Each journey takes the inputs of checkout_simulate plus expectations: the cart can be ordered, given payment or shipping methods are offered, codes apply, the total stays in a range. Without journeys it runs the ones in SHOPWARE_MCP_JOURNEYS (a JSON file). Nothing is ordered; carts are deleted. Returns { ok, passed, failed, results[] }.

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

Input Schema

Name	Required	Description	Default
`journeys`	No	Journeys to run

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.11.1Nov 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, it discloses that journeys exercise the real cart, that nothing is ordered, and that carts are deleted, clarifying the temporary side effects behind the safety hints. It also documents the environment-based default configuration and the top-level return shape.

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?

The description is dense but front-loaded, beginning with purpose and examples before covering expectations, defaults, cleanup, and output. Each sentence supplies operationally useful information without filler.

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?

Together with the detailed schema and annotations, this provides enough information to select and invoke the tool, including scenario structure, assertion types, optional-input behavior, side-effect boundaries, and returned summary fields. The lack of a detailed results[] item schema is a minor limitation rather than an invocation blocker.

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?

Although schema coverage is 100%, the description adds meaningful behavior for the sole parameter: omitting journeys loads them from SHOPWARE_MCP_JOURNEYS. It also usefully frames journey fields as checkout_simulate inputs plus assertions, though most individual assertion meanings are already supplied by the schema.

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 gives a specific action and resource: running synthetic customer buying paths through the shop's real cart and reporting which journey failed and why. Concrete examples and the comparison with checkout_simulate distinguish it from the sibling single-checkout simulation tool.

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 fixed-path examples and expectation checks make the intended use—validating multiple customer scenarios such as guests, promotion codes, and invoice payment—clear. It also explains the no-argument fallback, but stops short of explicitly saying when to choose checkout_simulate instead for an individual simulation.

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