Nepal's first MCP servers for eSewa & Khalti payments. TypeScript, HMAC-SHA256 signed, published to npm.
Server has 6 tools with complete input schemas and descriptions. Naming follows verb_noun convention (esewa_initiate_payment, khalti_verify_payment). Descriptions are present and substantive (100-200 chars), meeting baseline expectations. However, output schemas are not documented, responses are returned as JSON strings without formal schema declarations. Error handling exists but lacks recovery guidance (e.g., 'Try X next'). No tool annotations (readOnlyHint, destructiveHint). Parameters are well-described with constraints, but no enum declarations for categorical values. Missing idempotency guidance for payment operations.
Retrieve full transaction status details from eSewa by transaction UUID
Generate a signed eSewa ePay v2 form payload with HMAC-SHA256 signature for redirect-based payment initiation
Verify a completed eSewa payment and confirm successful transaction by querying the status API
Initiate a Khalti payment and retrieve the redirect URL for customer checkout
Look up the current status and details of a Khalti payment by payment ID (pidx)
Verify a Khalti payment is completed and safe to fulfill the order
Output schemas not documented. Tools return JSON strings without formal schema declarations. LLMs cannot predict response structure for downstream planning.
Error responses lack recovery guidance. errorResponse() returns error_code and message but no actionable next steps (e.g., 'Retry with valid transaction_uuid' or 'Check ESEWA_SECRET_KEY environment variable').
No tool annotations. Tools lack readOnlyHint, destructiveHint, or idempotentHint. Payment initiation and verification are read-only but not explicitly marked, forcing LLMs to infer safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
khalti_initiate_payment has optional nested objects (customer_info, amount_breakdown, product_details) with no schema constraints. LLMs cannot validate structure of nested fields.
No idempotency guidance. Payment initiation tools should document idempotency key behavior (transaction_uuid, purchase_order_id) to prevent duplicate charges on retry.