shopware-mcp

Shop settings

shop_settings

Read-onlyIdempotent

Reads Shopware trading settings for the whole shop or a sales channel, including inheritance, so you can check guest checkout, tax, login, cart, listing, newsletter, address, and document rules.

Instructions

Read the shop's trading settings from Shopware's system configuration, for the whole shop or one sales channel with inheritance: basic information (shop name, contact, legal pages), login and registration (guest checkout, double opt-in, password rules), cart, listing (products per page, sorting, reviews), tax, newsletter, addresses and documents. Only these domains are readable; mail servers, licences and plugin secrets are not, and credential-like keys are dropped. Use it for 'is guest checkout on?' or 'what is the default tax?'. Returns { salesChannelId, inherited, settings: { : { key: value } } }.

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_settings"
  }
}

Input Schema

Name	Required	Description	Default
`domains`	No	core.basicInformation: shop name, contact, legal pages, currency and language defaults; core.loginRegistration: guest checkout, double opt-in, password rules, required fields; core.cart: quantities, wishlist, subtotal and delivery time display, cart redirects; core.listing: products per page, default sorting, reviews, buy-in-listing, new badge; core.tax: default tax rate; core.newsletter: double opt-in for the newsletter; core.address: address form rules; core.saveDocuments: document storage
`salesChannelId`	No	Sales channel UUID for its effective (inherited) values; omit for shop-wide

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 readOnly/idempotent/non-destructive, and the description goes beyond them with inheritance semantics for sales channel resolution and the fact that credential-like keys are silently dropped from results. That sanitization behavior is exactly the kind of thing annotations cannot express. It doesn't discuss pagination or rate limits, but neither applies to this shape.

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-loads the operation, then the readable-domain inventory, then the exclusions, then use-case examples, then the return shape — a sensible escalation. Dense but every clause is load-bearing. The long domain enumeration sentence is heavy, 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 supplies the exact return shape { salesChannelId, inherited, settings } — filling the one real gap. Combined with inheritance rules and the read-exclusion list, an agent has everything needed to call it and interpret the response 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%, and the schema already spells out each domain enum value and the salesChannelId inheritance meaning, so the description's domain list is largely redundant. The description adds only the framing that omission means shop-wide. Baseline 3 is correct when the schema carries the parameter burden.

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?

States a specific verb and resource: 'Read the shop's trading settings from Shopware's system configuration', scoped to whole-shop or single sales channel. The enumerated domain list makes the exact surface area unambiguous. It doesn't name a sibling (e.g. shop_info) to contrast with, which keeps it shy of a 5.

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 example questions ('is guest checkout on?', 'what is the default tax?') that map directly to callable scenarios, plus an explicit exclusion boundary: mail servers, licences and plugin secrets are not readable. No explicit alternative tool is named for the overlapping cases (e.g. shop_info vs. shop_settings), so 4 rather than 5.

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