Loading ToolBench
MCP server for Easypaisa — mobile wallet, payments (Pakistan)
Easypaisa MCP has 8 tools with consistent naming (verb_noun pattern) and basic descriptions. All tools have input schemas with type definitions and parameter descriptions. However, descriptions are minimal (10-50 chars), lacking context on WHEN to use each tool, prerequisites, or error recovery guidance. Output schemas are not documented, LLMs cannot predict response structure. No error handling guidance, no idempotency markers, and no distinction between safe (read-only) vs destructive operations in descriptions. Tool composition is reasonable but lacks chaining hints (e.g., generate_token output fields needed by create_payment). Security: credentials injected via environment variables (good), but no audit logging or permission gates visible.
Check Easypaisa payment status.
Create a mobile account payment.
Create an over-the-counter payment.
Create an Easypaisa payment.
Generate a payment token.
Get transaction statement.
Inquire about a transaction.
Descriptions are too brief (10-50 chars). LLMs cannot determine WHEN to use each tool or distinguish between similar payment creation methods (create_payment vs create_ma_payment vs create_otc_payment). Expand to 100-200 chars explaining use case, prerequisites, and differences.
Output schemas are not documented. Tool handlers return JSON.stringify(result) as plain text, but LLMs cannot predict response structure (fields, types, nested objects). Document what each tool returns (e.g., create_payment returns {transactionId, status, timestamp}).
No error handling guidance. Tool handlers catch errors but return raw JSON.stringify(error). LLMs receive no actionable recovery hints (e.g., 'Invalid mobile number format. Expected 03XXXXXXXXX'). Add error classification (retryable vs user-fixable) and recovery suggestions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Refund an Easypaisa payment.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads (check_status, get_statement) from destructive writes (refund_payment, create_payment). Add annotations to guide agent planning and retry logic.
Tool composition lacks chaining hints. generate_token produces a payment_token, but create_payment description does not mention that token can be passed. Similarly, create_payment output should include order_id for use in check_status. Add dependency hints in descriptions.