Skip to main content
Glama
Sign In
Payware MCP Server

Payware MCP Server

Official
by payware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

payware_products_delete_schedule

DestructiveIdempotent

Permanently delete a product's price schedule using its product and schedule IDs. The action cannot be undone and requires a Premium plan.

Instructions

[Merchant] Delete a price schedule. This action cannot be undone. 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_delete_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the irreversibility warning is reinforcing rather than new. The plan-gating rule and the specific 403 failure mode are behavior beyond what the annotations or schema expose, which is genuine added value; it stops short of describing the success response or whether dependent airings are affected.

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?

Two tight sentences: the action first, then the consequence and the eligibility gate. No filler, and the most decision-relevant information (this is irreversible and plan-restricted) is front-loaded.

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 a destructive 5-parameter mutation with full annotation coverage and no output schema, the description covers the two things an agent most needs to know before calling: it cannot be undone and it will 403 off-plan. It would be complete at 5 with a note on what deletion returns or whether related schedules/airings are also removed.

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 required productId and scheduleId are already documented in the schema. The description adds nothing about parameter meaning or the authentication parameters (privateKey, partnerId), so baseline 3 applies.

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 description names a specific verb and resource ('Delete a price schedule') that cleanly separates it from the create/get/update schedule siblings. The '[Merchant]' prefix also signals the actor scope, so an agent knows exactly what is being removed.

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?

It gives a hard eligibility condition (Premium/PRM only, 403 otherwise) that tells the agent when this call will fail, which is real usage guidance. It does not name an alternative operation (e.g., update_schedule to retire a schedule without deletion), so a 4 rather than a 5.

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