Skip to main content
Glama
Sign In
Payware MCP Server

Payware MCP Server

Official
by payware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

payware_products_update_schedule

DestructiveIdempotent

Updates an existing product price schedule by reading it first to preserve omitted fields. Use it to change dates, discounts, corrections, or descriptions; Premium plan only.

Instructions

[Merchant] Update an existing price schedule. Only provide fields you want to change. The tool reads the schedule (and the product's time zone) first and sends it whole: the server resets a field a partial update leaves out (the discount to 0%, the dates to today), a server defect. Premium (PRM) plan only: the server answers 403 on any other plan (for an ISV, the merchant's plan).

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": {
      "productId": "<productId>",
      "scheduleId": "<scheduleId>"
    },
    "name": "payware_products_update_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateToNoSchedule end date (YYYY-MM-DD format)
dateFromNoSchedule start date (YYYY-MM-DD format)
partnerIdNoMerchant partner ID (uses PAYWARE_PARTNER_ID env var as default)partner_12345
productIdYesProduct identifier (starts with 'pr')
privateKeyNoRSA private key for authentication (uses environment-specific private key as default)
scheduleIdYesSchedule identifier
useSandboxNoUse sandbox environment
descriptionNoSchedule description
correctionTypeNoPrice correction method
correctionValueNoCorrection value (positive number with max 2 decimals)
priceCorrectionNoPrice correction direction

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations (destructive, idempotent, open-world), the description discloses non-obvious internals: the tool performs a read-modify-write using the product's time zone, and the server zeroes out omitted fields (discount to 0%, dates to today) due to a server defect. It also documents the 403 plan restriction. This is exactly the kind of hidden behavior an agent could not infer from structured fields.

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 sentences, front-loaded with the action, then the partial-update contract, then the plan gate. Every clause carries information; the only mild cost is the dense embedded parenthetical about the server defect, which is worth the words but slows parsing slightly.

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?

For an 11-parameter destructive mutation with no output schema, the definition covers the risky parts: partial-update safety, field-reset behavior, and plan authorization. It omits return shape and whether authentication parameters (privateKey/partnerId) need to be passed explicitly, but the schema supplies defaults and annotations cover the safety profile.

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 baseline is 3, but the description adds consequence-level meaning the schema lacks: omitting dateFrom/dateTo resets dates to today, and omitting correction fields resets the discount to 0%. That tells the agent which optional parameters are effectively load-bearing even though only productId and scheduleId are required.

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?

"Update an existing price schedule" states a specific verb and resource, and the phrase "only provide fields you want to change" establishes partial-update semantics. It is clearly distinct from create/get/delete schedule siblings by name and by the word "existing," 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 Guidelines4/5

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

The description gives a real precondition: Premium (PRM) plan only, with an explicit failure mode (403) and even the ISV caveat about whose plan is checked. It also tells the caller to send only changed fields. It does not explicitly route to create_schedule or get_schedule, but the update-vs-create distinction is unambiguous.

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