Skip to main content
Glama
Payware MCP Server

Payware MCP Server

Official
by payware

payware_poi_set_price

DestructiveIdempotent

Set a pending price on a POI for customer payment, moving the POI to READY until a scan or TTL expiry.

Instructions

[Merchant] Set a pending price on a POI for customer payment.

Authentication: your own JWT (an ISV makes the same call on your behalf). Endpoint: PUT /poi/{poiId}/price Use Case: Set the amount a customer should pay when they scan the POI.

The POI moves to READY and waits for a scan until the TTL expires. The scan creates the transaction and the POI is BUSY until the sale is final.

Only amount, currency and ttlSeconds are accepted. There is no description, callback URL or passback field on a price - the callback URL is set on the POI when it is created, and a POI without one sends no callbacks.

Keep the returned sessionToken until the sale has a final status: pass it to payware_poi_get_status to read that sale's transaction and outcome.

Required: POI ID, amount, currency.

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": {
      "poiId": "<poiId>",
      "amount": "<amount>",
      "currency": "<currency>"
    },
    "name": "payware_poi_set_price"
  }
}

Input Schema

NameRequiredDescriptionDefault
poiIdYesThe POI identifier (format: pi + 8 alphanumeric chars, e.g., piABC12345)
amountYesPayment amount (e.g., '25.50'), positive and no finer than the currency's smallest unit
currencyYesISO 4217 currency code (e.g., 'EUR', 'USD', 'GBP')
ttlSecondsNoSeconds until the price expires if nobody scans it (60-600). Defaults to the POI's own ttlSeconds.
useSandboxNoUse sandbox environment for testing

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (destructive/openWorld/idempotent), the description discloses the full state machine: POI moves to READY and waits for a scan until TTL expires, then goes BUSY until the sale is final. It also flags the operational requirement to retain the returned sessionToken and explains that callback URLs live on the POI rather than the price, which is context the annotations cannot convey.

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?

Front-loaded purpose sentence followed by short bolded sections (Authentication, Endpoint, Use Case, Required) that let an agent scan to the relevant fact. Every paragraph carries distinct information — no filler or repetition of the schema.

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?

For a mutating, open-world payment tool with no output schema, the description covers auth mode, endpoint, state transitions, TTL behavior, the returned sessionToken and its follow-up tool, and the callback caveat. Nothing an agent needs to invoke it safely and 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; the description earns above that by explicitly enumerating what is accepted ("Only amount, currency and ttlSeconds") and by ruling out description, callback URL and passback fields that an agent might otherwise assume exist. It restates the required set, which slightly duplicates 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 opening line gives a specific verb and resource ("Set a pending price on a POI") plus the business intent ("for customer payment"), and the endpoint line confirms the operation shape. It is immediately distinguishable from sibling reads like payware_poi_get_status and from POI creation.

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 "Use Case" line plus the READY/BUSY lifecycle narrative make clear when this tool applies, and it explicitly routes the agent to payware_poi_get_status to read the resulting sale. It stops short of naming payware_poi_cancel_price as the counterpart for abandoning a pending price, so it is clear but not exhaustively comparative.

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