Loading ToolBench
MCP server for integrating Paytm payment gateway, enabling payment link creation, transaction management, refund processing, and order tracking
Server has 7 tools with basic descriptions and schemas, but significant gaps limit production readiness. Tool names follow verb_noun convention (create_payment_link, fetch_payment_links, etc.), which is good. However, descriptions lack LLM-optimized structure, they are verbose (200-400 chars) and include implementation details rather than clear WHEN/WHY guidance. Parameter schemas are present but incomplete: many lack type constraints (e.g., 'amount' is string not float; 'time_range' and 'order_search_type' lack enums despite being constrained values). Output schemas are undocumented, tools return List[PaymentLink] or List[Transaction] but these types are never defined in the source. Error handling is minimal: most tools catch exceptions and return str(e), which gives LLMs no recovery guidance. Security concern: PAYTM_KEY_SECRET and PAYTM_MID are injected via environment, which is correct, but no audit logging or permission gates are visible.
Check the status of a previously initiated refund. This operation allows the merchant to check the status of a previously initiated refund. The refund status can be checked for a specific order and refund reference ID.
Create a new payment link for receiving payments. This operation generates a unique payment link that can be shared with customers for accepting payments. The link can be customized with recipient details, purpose, customer details and amount.
Fetch the list of orders from Paytm within a date range of 30 days and never assume from_date and to_date. This operation allows the merchant to retrieve a list of orders that have been created within a specified date range. The list can be filtered by order status and search type, and can be paginated to handle large datasets.
Retrieve all payment links created by the merchant. This operation returns a comprehensive list of all payment links created, including both active and expired links. Each link entry contains details such as: - Link ID - Link Name - Short URL - Status - Creation Date - Expiry Date
Output schemas undocumented. Tools return List[PaymentLink], List[Transaction], or str, but PaymentLink and Transaction types are never defined in source. LLMs cannot plan downstream calls without knowing response structure.
Parameter type mismatches. 'amount' declared as string but semantically a float; 'time_range', 'order_search_type', 'order_search_status' are free-form strings but should be enums. Invites hallucinated invalid values.
Error handling returns raw exception strings (str(e)). No recovery guidance, categorization, or actionable next steps. LLMs cannot distinguish retryable from fatal errors.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
Fetch the list of refunds for the merchant within a date range of 30 days and never assume start_date and end_date. This operation allows the merchant to retrieve a list of refunds that have been initiated within a specified date range. The list can be sorted by date and paginated to handle large datasets.
Retrieve all transactions associated with a specific payment link. This operation provides detailed transaction history for a given payment link, including successful and failed transactions.
Initiate a refund for a specific transaction. This operation allows the merchant to initiate a refund for a previously completed transaction. The refund can be initiated for a specific amount, and the refund reference ID will be used to track the refund request.
Descriptions are verbose (200-400 chars) and include implementation details. Lack clear WHEN/WHY guidance. E.g., fetch_refund_list says 'within a date range of 30 days' but doesn't explain when to call it vs fetch_order_list.
No pagination limits documented. fetch_payment_links, fetch_refund_list, fetch_order_list accept page_size but no max is enforced or stated. Could return thousands of items, exhausting context.