Skip to main content
Glama
Sign In
shopware-mcp

shopware-mcp

by bnymnDev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List shipping methods

shipping_methods_list
Read-onlyIdempotent

Lists shipping methods with active flag, delivery time, tracking URL pattern, availability rule and assigned sales channels. Filter by active status or sales channel to audit and configure shipping options.

Instructions

List shipping methods with active flag, delivery time, tracking URL pattern, availability rule and the sales channels they are assigned to. Filter e.g. active=true or salesChannels.id. Returns { total, page, limit, items[] }.

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

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page
sortNoSort order; defaults per tool
termNoFull-text search term
limitNoItems per page, max 50 (default from SHOPWARE_MCP_DEFAULT_LIMIT)
fieldsNoExtra raw entity fields to add to each item, e.g. ['customFields', 'ean']. Dot-paths allowed.
filterNoCriteria filters, combined with AND

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.1

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds genuine value by stating the response envelope { total, page, limit, items[] } and the fields carried per item, but says nothing about default page size, maximum results, or ordering behavior.

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?

Three tight sentences: payload fields first, filter examples second, return shape last. No filler, though the middle filter sentence is terse enough to read as an afterthought rather than structured guidance.

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 six optional params and no output schema, the description covers what is returned and which fields matter, which is the main gap it needed to close. Remaining shortfall is pagination defaults and sort semantics, which the agent must infer from the schema alone.

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%, so the schema already documents page, sort, term, limit, fields and filter thoroughly. The description's filter examples ('active=true', 'salesChannels.id') add entity-specific field names beyond the generic Criteria schema, but that is the only marginal addition and it does not explain syntax.

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+resource ('List shipping methods') and enumerates the entity fields included in each item (active flag, delivery time, tracking URL pattern, availability rule, sales channels). The resource is clearly distinct from siblings like payment_methods_list, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the 'Filter e.g. active=true or salesChannels.id' line hints at common retrieval patterns but never says when to choose this tool over payment_methods_list or a broader entity_search. No when-not or prerequisite guidance.

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

Deploy Server

Other Tools