Skip to main content
Glama
Sign In
Payware MCP Server

Payware MCP Server

Official
by payware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

payware_utils_format_json_deterministic

Read-onlyIdempotent

Formats JSON payloads with deterministic key sorting to ensure consistent SHA-256 hashes and payware API compliance.

Instructions

[Merchant] Format JSON payload with deterministic key sorting for consistent SHA-256 calculation and payware API compliance

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": {
      "payload": "<payload>"
    },
    "name": "payware_utils_format_json_deterministic"
  }
}

Input Schema

NameRequiredDescriptionDefault
payloadYesJSON payload to format with deterministic serialization
showComparisonNoShow comparison between standard and deterministic JSON
calculateSHA256NoCalculate SHA-256 hash for JWT contentSha256 usage
validateConsistencyNoValidate that multiple serializations produce the same result

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, which fits a pure formatting operation. The description adds the useful behavioral claim that sorting is deterministic and feeds SHA-256, but says nothing about the response — what the comparison output or hash looks like — which matters since no output schema exists.

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 front-loaded sentence covering purpose and motivation, with the '[Merchant]' scope tag up front and no filler. It is dense and specific, though it stops short of any second sentence that would explain the return.

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?

For a four-parameter tool with a nested payload object and no output schema, the description should hint at what comes back (formatted JSON, optional comparison, SHA-256 hash). Safety is covered by annotations, but the return surface is left entirely undocumented.

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 payload, showComparison, calculateSHA256, and validateConsistency are already fully documented in the schema with defaults. The description mentions deterministic serialization but adds no semantics for the three boolean flags beyond what the schema states, so the baseline of 3 applies.

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 gives a specific verb and resource ('Format JSON payload with deterministic key sorting') plus the reason it exists (consistent SHA-256 calculation and Payware API compliance). It does not explicitly distinguish itself from the sibling payware_utils_format_request, so an agent must guess between the two formatters.

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?

Usage is implied rather than stated: the mention of SHA-256 and API compliance signals when this matters, but there is no explicit 'use this when... / use X instead' guidance and no prerequisite or exclusion statements. The agent can infer the context but is not routed to or away from the sibling formatter.

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