Skip to main content
Glama
Sign In
Payware MCP Server

Payware MCP Server

Official
by payware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

payware_shops_list

Read-onlyIdempotent

List merchant shops and their codes so you can pass a valid shop or shopCode before creating transactions, products, or POIs, avoiding wrong-outlet fallback errors.

Instructions

[Merchant] List the merchant outlets (shops) the caller can act on.

Endpoint: GET /shops

Use this before any call that takes a shop / shopCode. Creating a transaction, creating a product, creating a POI and batching POIs all take one, and an invalid code is a 400 (ERR_INVALID_SHOP_CODE). Omitting it falls back to the merchant's default shop, which is a reasonable guess for a single-outlet merchant and the wrong outlet for everyone else - the sale lands against the wrong shop, and nothing about the response says so.

Returned per shop (server ShopDTO): code (the value to pass as shop / shopCode), name, isDefault, ecommerce, country and the shop's label, image and terms URLs.

⚠️ Requires Standard or Premium. A Basic merchant gets 403.

Note on financial institutions: banks do not own shops. A bank principal calling this gets 403, not an empty list.

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

Input Schema

NameRequiredDescriptionDefault
partnerIdNoPartner ID from the payware dashboard. Uses PAYWARE_PARTNER_ID env var as default.
privateKeyNoRSA private key for JWT signing. Uses the environment-specific key as default.
useSandboxNoUse sandbox environment for testing

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

A4.4/5.0
Behavior3/5

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

The annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered; the description adds genuinely useful context beyond that, including the 403 for Basic merchants and for bank principals, plus the silent default-shop fallback. However, it repeats the safety profile implicitly and says nothing about pagination or response size behaviour, so it adds value without being exceptional.

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 purpose and the 'use before' rule, then layers endpoint, return shape and access warnings; the bold headers make it skimmable. Slightly verbose in the doubled 403 messaging (tier requirement and financial-institution note both restate the same failure mode).

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?

There is no output schema, and the description compensates by enumerating the returned ShopDTO fields including which one is the value to pass downstream. Combined with tier requirements and error conditions, an agent has everything needed to call this correctly and interpret the result.

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 description coverage is 100%, so the three auth/config parameters are already documented and the description needn't compensate. It does add meaning about how the returned `code` maps to the `shop` / `shopCode` inputs elsewhere, which helps an agent use the output correctly.

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 ('List the merchant outlets (shops)') and scopes it to what the caller 'can act on'. An agent can immediately tell this apart from the campaign, product or POI list siblings.

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

Usage Guidelines5/5

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

Gives explicit when-to-use guidance ('Use this before any call that takes a shop / shopCode'), names the concrete operations that need it, and explains the failure mode of skipping it (400 ERR_INVALID_SHOP_CODE, or silent fallback to the wrong default shop). It also carves out when the tool is not available (Basic tier, bank principals).

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