Skip to main content
Glama
Sign In
Payware MCP Server

Payware MCP Server

Official
by payware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

payware_generate_documentation

Read-onlyIdempotent

Generates partner-specific API integration documentation with base URLs, request-signing steps, and operation routes in a chosen programming language.

Instructions

[Merchant] An integration overview for one partner type: base URLs, how requests are signed, and every operation payware_generate_code_example can write, with its route.

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_generate_documentation"
  }
}

Input Schema

NameRequiredDescriptionDefault
languageNoThe language the overview's next steps refer to: python, nodejs, php, java, csharp, curl. Default python.
partner_typeNomerchant, isv or payment_institution. Decides the operations listed and how requests are signed. Default merchant.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

B3.2/5.0
Behavior3/5

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

Read-only, idempotent, non-destructive, closed-world behavior is already fully declared by the annotations, so the description's marginal job is to describe the produced artifact. It does say the document contains base URLs, signing instructions, and a per-operation route list, and that partner_type changes signing and the operation set. It does not say the output format (markdown vs. JSON), length, or whether it is returned inline vs. written to a file.

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?

A single dense sentence with no filler, and the subject (the overview) is front-loaded. The only blemish is the unexplained '[Merchant]' bracket prefix, which adds noise before the actual purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must convey what comes back, and it partially does by enumerating the document's sections. It leaves the delivery format and size unspecified, and the interaction between language and partner_type ('next steps' vs. signing) is only implied. Adequate for a two-enum, parameterless generator, but not complete.

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 coverage is 100% and both enums are fully enumerated with defaults, so the schema does the heavy lifting. The description adds only that partner_type is the 'partner type' the overview targets and that language governs the 'next steps' section, which largely restates the schema text. Baseline 3 is appropriate.

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?

The description states the artifact precisely: an integration overview for one partner type covering base URLs, request signing, and every operation with its route. The aside that it lists the operations payware_generate_code_example can write distinguishes it from that sibling. It never says the word 'generate' or the output format, but the scope is unambiguous.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance. The reference to payware_generate_code_example is about content overlap, not routing ('use that tool when you want runnable code, this one for an overview'). The bracketed '[Merchant]' prefix reads as a templating artifact rather than instruction, and no prerequisites are stated.

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