Loading ToolBench
AI-native payment MCP server for West Africa. Unified gateway for CinetPay, Wave, Hub2/Ecobank, and PAPSS payment rails.
WariMCP provides 9 well-structured payment tools with complete input schemas and descriptions. Naming is clear and verb-based (initiate_, verify_, list_, generate_, authorize_and_pay). Descriptions are substantive (100-200 chars typical). However, output schemas are not documented in the provided source, the LLM cannot predict response structure. Tool composition is reasonable (payments, payouts, verification, links, providers) but lacks error handling guidance and recovery patterns. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) detected. Parameters are well-typed with enums where appropriate (method enum in initiate_payout). Security approach (API key injection, database-backed config) is sound, but no explicit permission gates or audit logging structure visible in tool definitions.
Execute a payment authorized by an agent-signed Ed25519 mandate without accessing the agent's private key
Generate a reusable payment link with optional provider selection
Initiate a payment with optional provider selection, returning a payment result with transaction ID and payment URL
Initiate a payout to a recipient with optional provider selection
List all configured payment providers with their capabilities, supported currencies, countries, and methods
List transactions with optional filtering by provider, status, limit, and offset
Refund a payment transaction, optionally specifying amount and reason
Output schemas not documented. LLMs cannot predict response structure (fields, types, nested objects). This forces agents to guess at response shapes and breaks downstream tool chaining.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe read operations from writes without explicit marking. Verification tools should be marked readOnly; payment/refund/payout tools should be marked destructive.
No error handling guidance or recovery patterns in tool descriptions. When a payment fails, the LLM has no recovery path, descriptions should specify 'retryable', 'user-fixable', or 'fatal' categories.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
Verify the status of a payment transaction by transaction ID
Verify the status of a payout by payout ID
authorize_and_pay uses nested object input (mandate with nested properties). This is harder for LLMs to construct than flat parameters. Consider flattening to mandate_amount, mandate_currency, mandate_merchantRef, mandate_expiresAtMs, mandate_nonce for clarity.
list_transactions accepts optional limit and offset but no documented max limit or default. Without constraints, LLMs may request unreasonable result counts, causing context window overflow.
No idempotency documentation for write operations. initiate_payment and initiate_payout accept idempotencyKey, but descriptions don't explain the replay-safety behavior. LLMs need to know: does calling twice with same key guarantee exactly-once? What does the response contain on second invocation?