Loading ToolBench
Exposes PayBySquare generation, decoding, and compliance checking functionality through the Model Context Protocol
The server provides 4 tools with mostly complete schemas and adequate descriptions. Tool naming follows verb_noun convention (generate_, decode_, check_, verify_). All tools have input schemas with type definitions and descriptions for most parameters. However, output schemas are not documented, error handling guidance is minimal, and some parameter descriptions could be more detailed. The generate_paybysquare tool has good contextual descriptions (e.g., SWIFT/BIC code rationale), but check_compliance and verify_roundtrip have incomplete parameter documentation.
Check payment data compliance with PayBySquare and banking standards. Returns detailed compliance report.
Decode a PayBySquare QR code from base64-encoded PNG image. Returns payment data.
Generate a PayBySquare QR code PNG image from payment data. REQUIRED: beneficiaryName (recipient's full name). RECOMMENDED: swift (BIC code for international transfers). Saves QR code to file and returns file path.
Verify that payment data survives encoding/decoding without loss. Useful for testing data integrity.
Output schemas not documented. Tools return unstructured responses or responses with unknown field structure. LLMs cannot plan downstream composition or extract specific fields.
Error handling and recovery guidance missing. No documented error cases, no guidance on what to do if decoding fails, compliance check fails, or roundtrip verification detects loss.
Parameter descriptions lack constraint details. Fields like 'iban', 'variableSymbol', 'constantSymbol' have format descriptions in the schema but descriptions don't mention length, regex, or character restrictions. LLMs cannot validate inputs without reading JSON Schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
decode_paybysquare description is too brief (9 words). Does not explain what 'payment data' structure is returned, what imageBase64 format is required (PNG only?), or error cases.
check_compliance and verify_roundtrip input schemas use minimal field descriptions. Many nested properties (variableSymbol, constantSymbol, specificSymbol, originatorReference, beneficiaryAddress.street, beneficiaryAddress.city) lack inline descriptions in these tools, forcing LLMs to reference the generate_paybysquare schema.