Loading ToolBench
MCP server for integrating Paystack payment processing capabilities, enabling payment initialization and verification
The Paystack MCP server has two tools with basic definitions visible in the manifest. However, both tools suffer from incomplete schema documentation, missing parameter descriptions for some fields, and vague descriptions that don't fully explain when and why to use each tool. The tool names are adequate (initialize_payment, verify_payment) but descriptions are minimal and lack context about the operations' consequences or prerequisites. Input schemas are partially present but metadata field is typed as 'object' without inner structure documentation. Output schemas are not documented anywhere in the provided code, making it impossible for LLMs to plan downstream operations or know what fields to expect. Error handling is present in code but not exposed in tool definitions. The server follows HTTP transport (positive), but tool registration appears to read from a manifest file rather than being explicitly defined in code, which limits visibility into the actual tool contract.
Initialize a payment transaction on Paystack
Verify a payment transaction on Paystack using a reference
Output schemas not documented. Tool returns are inferred from Paystack API response types visible only in internals/paystack/types.go (InitializePaymentResponse, VerifyPaymentResponse), but no output schema is present in tool definitions or accessible via the manifest. LLMs cannot plan downstream tool calls without knowing what fields to expect.
Metadata parameter (in initialize_payment) typed as 'object' with no inner schema or description. LLMs cannot determine what metadata structure Paystack expects. This violates the constraint that all parameters must have actionable descriptions explaining format and allowed values.
Tool descriptions are under 100 characters and lack context. 'Initialize a payment transaction on Paystack' does not explain what it returns (authorization_url?), when to call it vs verify_payment, or what the reference parameter uniqueness requirement is. Descriptions must state WHAT, WHEN, and any prerequisites (pattern:tool-description baseline 194 chars avg).
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Error handling not exposed in tool definitions. Code shows basic HTTP error responses ('bad request', 'internal server error'), but tool definitions do not document error cases, recovery hints, or categorization (retryable vs user-fixable). Per pattern:recovery-guide, error responses must guide the LLM on next steps.
Currency parameter in initialize_payment has no enum constraint. Description says 'Currency code (e.g., NGN, USD)' but does not list valid values or constrain input. LLMs may hallucinate invalid codes (e.g., 'DOLLARS', 'Nigerian Naira'). Should declare valid currency codes as an enum.
No pagination or result limits documented. initialize_payment returns a single transaction object (acceptable), but if either tool ever returns collections, there is no documented limit or pagination mechanism. Per pattern:paginated-result baseline, tools must accept page/offset and limit and return total count or next_cursor.