Skip to main content
Glama
Payware MCP Server

Payware MCP Server

Official
by payware

payware_generate_code_example

Read-onlyIdempotent

Generate signed Payware API request code examples in Python, Node.js, PHP, Java, C#, or cURL, including RS256 JWT authentication and content SHA-256 handling.

Instructions

[Merchant] Generate a complete program for one payware API call, or the JWT helper, in python, nodejs, php, java, csharp, curl. Each program signs its request as payware requires (RS256 JWT with contentSha256 for a body, on behalf of a merchant for an ISV) and calls the real route. finalize_transaction (payment institutions) is the whole institution flow: process, EXECUTING immediately before money moves, then CONFIRMED once the Merchant Leg has completed, or FAILED.

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": {
      "operation": "<operation>"
    },
    "name": "payware_generate_code_example"
  }
}

Input Schema

NameRequiredDescriptionDefault
languageNopython (requests, PyJWT), nodejs (axios, jsonwebtoken), php (cURL, firebase/php-jwt), java (Java 11 HttpClient, no dependencies), csharp (.NET 6 HttpClient, no dependencies) or curl (curl and openssl). Default python.
operationYesThe operation. Transactions: create_transaction, get_transaction_status, process_transaction, cancel_transaction, get_transaction_history, and for payment_institution finalize_transaction (process, EXECUTING, then CONFIRMED or FAILED, all on /api/transactions/{transactionId}). Products and audio (merchant, isv): create_product, get_product, list_products, update_product, delete_product, register_audio, get_audios, get_audio, update_audio, delete_audio. OAuth2 (isv): obtain_token, get_token_info, rotate_token. Reports (production only): list_reports, generate_report, get_report_status, export_report. authentication: the JWT helper on its own.
partner_typeNomerchant, isv (calls on behalf of a merchant, and the OAuth2 token endpoints) or payment_institution. Decides which operations exist and how the JWT is signed. Default merchant.
include_commentsNotrue (default): the program with comments, inside a page that names the route and what to know about it. false: the program alone.
include_error_handlingNotrue (default): report a failed status or a network error. false: the shortest program.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the readOnly/idempotent/closed-world annotations, the description discloses the important trait that each generated program signs its request (RS256 JWT with contentSha256 when a body is present, merchant-on-behalf-of-ISV) and calls the real route rather than a mock. It also notes that include_comments wraps the program in a page naming the route, which is output-format context the annotations do not cover.

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?

Two sentences, front-loaded with the core promise, and every clause carries information; the closing finalize_transaction sentence is long and reads more like schema material than tool-purpose guidance, but it still earns its place by flagging a money-moving flow.

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 5 fully documented parameters, no output schema, and three enums, the definition covers the decisions an agent must make (operation, partner_type, language, comment and error-handling toggles) and hints at the returned shape ('inside a page'). Minor gaps remain: nothing states whether generation is instant or how failures are surfaced.

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 adds real value on top by explaining that finalize_transaction is the entire institution flow (process, then EXECUTING immediately before money moves, then CONFIRMED or FAILED) and that partner_type governs both which operations exist and how the JWT is signed. It also clarifies that 'authentication' yields the JWT helper alone, which the enum description only partly conveys.

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 artifact ('Generate a complete program for one payware API call, or the JWT helper') plus the six target languages, which is enough to separate it from siblings like payware_authentication_create_jwt_token or payware_operations_create_transaction that perform the operation themselves rather than emit example code.

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?

Scope is implied (one API call per generated program, or the standalone JWT helper via authentication), but there is no explicit when-to-use vs. when-not guidance and no sibling is named as an alternative for e.g. documentation generation or direct operation calls. An agent must infer that this is the 'show me sample code' tool.

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